On Mon, Aug 01, 2005 at 06:23:59PM +0200, Sven Mueller wrote: > Gerrit Pape wrote on 31/07/2005 19:17: > > You might be interested in this web page > > http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes-to-avoid.html > > ARG. Not that page again. (OK, I'm exaggerating.) Granted, it does > mention a few good things, but also makes various mistakes itself > IMHO: > Most importantly, it discourages use of syslog. Even with all its > disadvantages, I definately prefer daemons using syslog over any other > mechanism mostly because I (as the admin) can easily redirect the log > to > remote hosts, log different parts of the information to different logs > (like log everything above debug to a file only kept for 24h while > logging everything from warn upwards to some file kept for a month). > With modern syslog implementations like syslog-ng I am able to divide > or > merge logs from different programs or syslog facilities as I want. I > wouldn't be able to do so with daemons which always log to > stdout/stderr.
Sure you are, runit's logging facility provides all this, and additionally it provides some more features such as automatic log rotation, limiting logs by size or age. See the svlogd(8) man page. And it discourages the use of syslog for a reason; here's two major flaws of standard syslog in short: o $ ls -l /dev/log srw-rw-rw- 1 root root 0 Aug 3 14:50 /dev/log World writable socket, try this DOS as some unprivileged user $ while :; do echo foo; done |logger & o $ grep 'void syslog' /usr/include/sys/syslog.h extern void syslog (int __pri, __const char *__fmt, ...) Function returning void, applications cannot know if the messages actually have been written to disk. Did you know that you can lose log messages when just doing '/etc/init.d/sysklogd restart'? But I admit, syslog will not get obsolete in the near future, if at all. It can still be used under runit, I suggest the socklog package for that. > The other advices are good to keep in mind though they do have flaws > themself because they don't even mention the downsides of the approach > they are recommending. One example is the don't background advice. A > daemon should allow some mechanism to put it in the background and > detach with its filedescriptors (especially STDIN/STDOUT/STDERR) > closed, > so that the shell which started it can exit cleanly. Sorry, I don't understand this. With a guaranteed process state, there's no need to fiddle with filedescriptors, such as close all fds up to the maximum possible or so, you exactly know which fds are open if the run scripts starts. In the script you can easily close stdin and co. (exec 0<&-; exec 1>&-); or use the chpst(8) program to alter the process state for the service daemon to your wishes. The (run script) shell exits cleanly when it replaces itself with the service daemon. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. _______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
