[systemd-devel] [PATCH] allow explicit stdout/stderr configuration for SysV services

[Lennart Poettering]

On Tue, 01.03.11 22:37, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> > How are you planning to use this? connect stdout of all services to
> > /dev/null, and stderr to syslog? I guess such a default configuration
> > coming from upstream might make sense: that way all errors would go to
> > syslog, and the [ OK ] output would just go to /dev/null, since it is
> > duplicate with what systemd generates anyway.
> 
> Unfortunately there are far too many services that start multiple
> processes, so you cannot reply just on exit code to know whether all
> of them were successful or failed; so those [ OK ] actually provide
> valuable debugging information. And those services may not even print
> anything except OK or FAIL. So no, I do not think for legacy scripts
> splitting stdout/stderr is really desired.

Hmm, I see. I guess I can agree with this.

> > The only problem with that
> > I see is that syslog implementations started with sysv scripts would end
> > up in a cyclic loop, and I don't know how to fix this...
> >
> 
> Could you elaborate? Do you mean messages may be echoed back to
> stdout/stderr to create a loop?

Well, the problem goes like this: syslog.service is a SysV service. It
is pulled in by syslog.target. Now you enable your new feature, i.e. all
output to stdout and stderr of all SysV services will go to syslog, and
all sysv services will gain a dep on syslog.target. Boom, you have your
cyclic dependency: syslog.service and syslog.target will require each
other.

One fix could be to say that syslog implementations have to be non-sysv
services and hence have the problem go away. Or, alternatively have some
logic that ignores this option if "Provides: $syslog" is in the LSb
header? But that could be messy...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.