Improvements to daemon

Anonymous
2007-12-04
2013-04-17
  • Anonymous - 2007-12-04

    Hi,

    First, I want to thank you and Florent for taking the time to make this project a reality.
    It is a very good idea, I was planning to use lockrun, until I saw your development work. :)
    http://www.unixwiz.net/tools/lockrun.html

    However, there 2 main areas that need to be improved.
    First, your installer will copy the kthmld.sh file into /init dir. IMO this is not a viable approach. For people who write RPM (like myself), compiling the RPM will result into failure, due to directory write permissions for a generic user.
    I also noticed that the manuals are not GZiped.

    Second, I think it would be best to have a separate logging system. Currently your daemon logs everything to syslog. I believe it will be better to create a specific directory that will include the daemon logs, that can be rotated properly. In this way, we can identify easy the actual problems we are experiencing.

    I forwarded to Florent, one of my spec files, so we can look together at those issues.
    I,m not an experienced user with C, but I'm very comfortable with Unix, so we can work together to build a nice daemon, if you want.

    There is no way for me to attach a document here, I wanted to show you also the RPM spec file.

     
    • JPK

      JPK - 2007-12-04

      First of, I want to thank you for your comments on khtmld. There is still much to do, I know. The idea with a separate logging is a good one and should be easy to implement. You also could send me an email with the specs file at jpk@goatpr0n.de.
      The other thing a always pushing away from me, are the manual, sample configuration files and the init script. The "make install" command is very distribution based. I started experimenting with dpkg, cause I'm using Debian, but RPM is also an option.

       
    • Anonymous - 2007-12-04

      I can help you with the RPM's, I have a lot of experience to that area.
      Where I seek help is related to C programming the current tasks, listed above.
      Florent was very helpful to me recently with khtml2png, he also helped you a lot with your project, from what I see.

      From my point of view, we need to remove the /scripts/khtmld.sh install process. The file should be left in the /scripts directory, so users can use it, if they want. I will create a khtml.conf file that can contain all pertinent info, like log file location, khtmld user, etc. The executable (daemon) should read that .conf file, in order to find all needed data.

      Do you know a good software that could guide us, related to the points listed above?
      I always like to look at lighttpd code/structure. Then again, we don't also want to redo all from scratch, I'm sure.

      Since you and Floren have more experience then me, related to C++, I would like to know your opinion. Thanks.

       
      • JPK

        JPK - 2007-12-05

        Removing the script from installation is no problem. For reading a config file I would need to rewrite the config parser. Currently it simply reads the parameters and use them to invokde khtml2png. This would be a big point on my agenda, but I don't want to implement this big change with the next release. Adding parameters to the command line would be a first solution. Like a "--log /var/log/khtmld.log".

        I implement the logging with the next release.

         
    • Florent Bruneau

      Florent Bruneau - 2007-12-04

      I've not worked more than a few hours on khtmld: I've just implemented a few features I needed (mostly the suid mode). So, I don't think I deserved all this compliments.

      I don't think coding a separate logging system is really useful: most loggers (including sysklogd, syslog-ng...) can simply (by configuration tweaking) put the log in a separate files, depending on the identifier given to openlog(), that's just logger configuration.

       
    • Anonymous - 2007-12-04

      I think this is a good idea, Florent. If I write a bash script, I would use:
      # logger -f /var/log/khtmld/khtmld.log

      Can we do something similar in the daemon.c file? See this line:
      syslog(LOG_CRIT, "Error reading from pipe!");

      From my logic, the daemon should write the error message to /var/log/khtmld/khtmld.log file, instead of the system log. Also, we need to look at this from a RPM builder's side. The less edits we make to system files, better the application is.

      One good example is trying to copy the /scripts/khtmld.sh to a system folder, like the installed does now. By default this approach should be avoided, due to security issues that might appear.

      Let me know guys what you think.

       
      • JPK

        JPK - 2007-12-05

        I don't the a security issue by installing the khtmld.sh. When you run your server you might want to run khtmld on startup. The real problem is to decide which directory is the right one.

        Debian, Gentoo and other use /etc/init.d
        ArchLinux for example uses /etc/rc.d

        > The less edits we make to system files, better the application is.
        That's true, modifying syslog can frustrate users. On the other hand we have only one file we need to look at, when we need to check our system-health. But I will implement a separate logfile. I run khtmld on a system which sends more than a hundred URLs from time to time to the fifo... This can cause MASS syslog spamming. Yeah syslog supports filtering, but I am a lazy guy and don't man to read "man syslog-ng.conf" and realated stuff ;-)

         
    • Anonymous - 2007-12-05

      > Debian, Gentoo and other use /etc/init.d
      >
      Jay, I will give you 2 quick examples: lighty does have a .sh script but does not install it by default, memcached also. I think they chose this approach, because they want to avoid the issue you mentioned in your above post. This is a very good highlight you made and that's the number one reason why it should not be installed.

      If you build an RPM, then the right folder will be assigned by default, due to the internally defined directory variables. Plus, if you built the RPM, you will get an error related to copying the script to the /init.d directory because you are in a test environment. On the other hand, if you do it manually, it takes 2 seconds to copy the file to your preferred directory and start the daemon. Again, you avoid possible conflicts.

      > I run khtmld on a system which sends more than a hundred URLs from time to time to the fifo
      >

      Good point.
      I will have the deamon running on a system that will send hundred of URLs also.
      So that's the main reason I was concerned about the logs.

      I did not have the time to build an RPM with the start script I made yesterday, but I will email it to you tonight. I'm pretty sure you will like it a lot. I run CentOS on my test server, but with a source, you will be able to adapt the RPM easy to your distro.

       
    • JPK

      JPK - 2007-12-20

      I put up a first version of the daemon with the new logging mechanism It is only available through SVN. By default it is written to '/var/log/khtmld.log', but to change the log file you can pass as argument with the "-l" or "--log" flag. The output is not perfect and I plan to replace the [PRIO:0x%x] with a timestamp.

       

Log in to post a comment.