Just for the fun :

"Again, this turned out to be due to a change to D-Bus. Lennart Poettering had
been working on some changes to avoid libdbus’s awkward SIGPIPE handling
and replace it with the use of the MSG_NOSIGNAL flag. Unfortunately he’d
missed a case in the authentication code. The side-effect was that if the D-Bus
daemon had crashed, been killed, OOM’d, etc. during initial connection
– the connecting application would have gone too. Especially bad for an
init daemon.

Scott James Remnant"

Links :
https://web.archive.org/web/20120317110358/http://netsplit.com/2010/12/30/the-importance-of-being-tested/
https://lists.freedesktop.org/archives/dbus/2010-December/013813.html
http://free-desktop-dbus.2324887.n4.nabble.com/PATCH-sysdeps-unix-use-MSG-NOSIGNAL-when-sending-creds-td11858.html

Regards
zeanmi
--

Le lundi 15 février 2016, Rainer Weikusat a écrit :

> https://dvdhrm.wordpress.com/2015/06/20/from-af_unix-to-kdbus/
>
> is surely not "a RedHat originated conspiracy".
>
> This text claims to be about kdbus but it basically doesn't mention
> it at all beyond asserting the something claimed to be comparable
> would be "fundamentally flawed" (my words) and kdbus the magic fix
> for it, no technical details provided on that.
>
> But it contains a nice example of "cargo cult programming": Sending
> messages to an AF_UNIX SOCK_DGRAM socket via
>
> sendto(fd, "foobar", 7, MSG_NOSIGNAL, (struct sockaddr*)&destination,
> sizeof(destination));
>
> In 2010, a certain Lennart Poettering was going through the dbus
> (daemon) code replacing every send call with one specifying
> MSG_NOSIGNAL in order to avoid SIGPIPE signals when trying to write
> to a 'broken' virtual circuit[*] reported by Scott James Remnant in
> a blob entry which has since vanished from the web, he overlooked at
> least one which cause the dbus daemon to die suddenly (and the
> upstart test suite detected this). As shown above, this seems to
> have developed a life of its own in the meantime: MSG_NOSIGNAL
> serves absolutely no purpose for a datagram socket, especially an
> unconnected one.
>
> [*] The sane way to handle this would be to set the disposition of
> SIGPIPE to SIG_IGN and make sure to handle EPIPE errors.