Defining the workgroup objectives

[Gerrit Pape]

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/.