Defining the workgroup objectives

[Sven Mueller]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/attachments/20050805/57c14744/signature.pgp