[systemd-devel] Reason for IgnoreSIGPIPE=true by default

[Lennart Poettering]

On Fri, 25.07.14 20:22, Ansgar Burchardt (ansgar at debian.org) wrote:

Heya!

I think I replied to this since on IRC, but just for the sake of
completeness of the ML archives:

> I'm wondering what the reason for IgnoreSIGPIPE to default to true is.
> The documentation just states that

SIGPIPE is primarily something to ripple up shell pipelines right to
left, if something dies. EOF is usually used from left-to-right. That's
not really useful for normal daemons though, and as we try to provide a
good, useful execution environment for daemons, we turn this off. Of
course, shells should and suchlike should turn this on again.

>     Defaults to true because SIGPIPE generally is useful only in shell
>     pipelines.
> 
> But I don't think that this alone is a good reason to change the default.
> 
> It can confuse programs which use pipes and do not expect their signal
> handlers to be messed with, see [1] for the same issue in Python. As
> another example, "tar xf *.tar.gz" will fail on some archives if SIGPIPE
> is ignored[2].
> 
> Another problem is that this not only affects the program started by
> systemd itself, but leaks into all child processes as well. See [3] for
> a bug report against cron due to this (yes, can be worked around by
> setting IgnoreSIGPIPE=false for cron.service, but I believe systemd is
> wrong here).
> 
> Ansgar
> 
>   [1] <http://bugs.python.org/issue1652>

I think the Python guys did the right thing here, and reset the SIG_IGN
again before execing something else...

Also, to my knowledge bash is actually smart enough to reset this on its
own when it is invoked. Which sounds like the right thing to do. Maybe
this bug is specific to Debian's bash replacement, and should be fixed there.

In addition, note that for gettys/user shells and stuff we actually
explicitly set IgnoreSIGPIPE=no currently. Same for all sysv init
scripts, to provide compatible behaviour.

Lennart

-- 
Lennart Poettering, Red Hat