[Pkg-utopia-maintainers] Bug#823754: dbus service activation SIGPIPE disposition is not documented

[Ian Jackson]

severity -1 minor
retitle -1 dbus service activation SIGPIPE disposition is not documented
thanks

I wrote:
> The logfile contains entries like this:
> 
>   2016-04-08 12:15:12 UTC:/sbin/wpa_supplicant[3350] execd oddly
>   (parent /usr/bin/dbus-daemon[3349]): Broken pipe: SIG_IGN

This seems to be due to this code in dbus-spawn.c:

      else if (grandchild_pid == 0)
      {
          /* Go back to ignoring SIGPIPE, since it's evil
           */
          signal (SIGPIPE, SIG_IGN);

AFAICT this is used only for `activation'.  Reading documentation
about service activation, ISTM that the dbus service activation
interface is defined by dbus.

Therefore, it appears that programs that expect to be activated via a
dbus service in this way are supposed to also expect that SIGPIPE will
be ignored on entry.  (So I was wrong about wpa_supplicant.)

Personally this seems rather redundant, because presumably such
services might also be started separately, and if they want SIGIPE
ignored they'll have to do it themselves.  But I don't think it's
arguable that it is wrong of dbus to define its activation interface
this way, even though it's not how I would have done it.

However, it should be documented.

I think doc/dbus-specification.xml should say that services activated
via service files will be exec'd with SIGPIPE ignored.

Knowing this is particularly important for anyone who might write a
shell script which tries to do something nontrivial and then wrap or
become a dbus service.  Well-written shell scripts using pipes for
data processing typically rely on SIGPIPE for proper functioning.
(And it is difficult to reset SIGPIPE to SIG_DFL if it is ignored on
entry to the shell - the easiest way is often to do something like
re-execing via perl -e '$SIG{PIPE}=""'.)

Incidentally, this code was introduced upstream in git commit
90f939f155bd "dbus-spawn: set SIGPIPE to SIG_IGN before activating
services".  But the justification in the commit message, there, about
restarting journald and logging failing, seems doubtful to me.  If the
whatever logging library is in use is inclined to generate SIGPIPEs in
this situation, then other non-dbus-service users are at risk of
spuriously dying of SIGPIPE.  This problem is probably a question for
another day, but I thought I would mention it in case anyone reading
this felt like investigating whether this is a real problem and/or
filing another bug.

Thanks for your attention.

Ian.