Gerrit Pape wrote on 03/08/2005 20:32: > 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.
So svlogd graps daemon logging from their STDOUT/STDERR and magically adds information (capacity, loglevel)? > And it discourages the use of syslog for a reason; I didn't say syslog is perfect. But recommending logging to STDERR/STDOUT instead isn't doing anything better than syslog. It might avoid security flaws, but from the other side of the fence (i.e. when you are looking for configurability instead of security first), syslog is definately better. > 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 & As I said, syslog definately isn't perfect. > 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'? Yes I know. However, a restart shouldn't be necessary with a proper syslog daemon (a reload should be enough). However: Should other services/daemons block because syslog isn't reachable? Believe it or not: The fact that syslog messages can get lost is by design (i.e. that is intended behaviour). > But I admit, syslog will not get obsolete in the near future, if at all. I would be glad to see a secure replacement which doesn't have less features. And I'm talking not about an ABI (resp. /dev/log) compatible replacement, but an API compatible replacement, primarily. It should however provide the same information about a log message: The host it is sent from, the process sending it, the facility and loglevel and of course the message itself. From that point on, I would like to see a logging daemon at least almost as flexible as syslog-ng. >>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, I'm not talking about closing all FDs, just closing the standard STDIN/STDOUT/STDERR would be enough (on request per commandline option or by default with an option to disable that behaviour). > 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. Well, you are talking about runscripts again, I was making a general point: If I ask a program to become a daemon (i.e. some --daemon commandline option or by that programs default), it should detach itself from the console it was started on. If I ask a program to stay in foreground (some --foreground option or that programs default), there is no need to detach and it could even be counterproductive to try that. Actually, I would like daemons/services to act as the admin wishes, with either a) detach and background (become a classic daemon) b) stay in foreground, don't detach and fork childs as needed c) (rather exotic, but it might have its uses): background but don't detach, preventing the shell from exiting, but allowing more processes to be started from the same shell If at all possible, some standard commandline option to get each of these would be nice, but that is just a dream probably never becoming true. cu, sven
signature.asc
Description: OpenPGP digital signature
_______________________________________________ initscripts-ng-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
