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

[Andrey Borzenkov]

On Tue, Mar 1, 2011 at 10:07 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 01.03.11 11:04, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
>
>> > Hmm, how would you use this? Send SysV stdout to /dev/null, but SysV
>> > stderr to the console? Is this really advisable? i.e. are you sure that
>> > if current init scripts encounter an error they properly write warnings
>> > to stderr, instead of just echoing them to stdout?
>> >
>>
>> I do not really need SysVStandardError, it was just monkey job, you
>> know :) copy'n'paste from DefaultStandardOutput/Error
>
> Hee, I din't want to suggest that you should remove the stderr part from
> the patch. I just do wonder how precisely you are planning to make use
> of this, just to know the context for your patch. I can see good use in
> your patch, just wondering how precisely you'd make use of it and how
> you would ship things by default.
>

Actually my plans were really to redirect all output; different
handling of stdout/stderr was just "for the sake of completeness".

> I think if we do this, then we should have seperate options for stdout
> and stderr, simply to mirror how we do it for the the other stdio
> related options.
>
> 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.

> 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?