dbus.service does not recover dbus-daemon after spurious SIGTERM

[Simon McVittie]

On 05/04/16 19:10, Zizka, Jan (Nokia - CZ/Prague) wrote:
> Would it then make sense to configure dbus.service to trigger system reboot
> right away? Somethink like:
> 
> FailureAction=reboot

I am not going to do this upstream, because:

* it should never happen (if the dbus-daemon fails with SIGSEGV or
  something, that's a bug that should be investigated and fixed)
* the system dbus-daemon is not mission-critical on all systems
  (for example, consider a web server that happens to have dbus-daemon
  for communication with systemd or something: if dbus-daemon fails, it
  can still serve web pages)
* if it does happen, the administrator of a general-purpose computer
  (laptop, desktop, server) is somewhat likely to want the chance to
  recover or debug the situation
* that change would needlessly antagonise a significant number of users
  (in particular, change-averse sysadmins who don't necessarily
  understand why they have dbus-daemon in the first place)

If you are developing an embedded or special-purpose device where system
dbus-daemon failure makes the device useless, and your device is
designed to cope well with unexpected reboots, then by all means add
this to a vendor drop-in configuration file, perhaps
/usr/lib/systemd/dbus.service.d/reboot-on-failure.conf. Drop-in
configuration files are great for this sort of thing; I've used them for
similar purposes on embedded OSs myself.

> But that won't catch cases when dbus-daemon would exit successfully.

As far as I'm aware:

The system dbus-daemon should never exit successfully, except for when
systemd (or another init system) kills it as part of an orderly shutdown
(in which case rebooting would be silly).

The session dbus-daemon should never exit successfully, except for when
dbus-launch or systemd --user (or another pseudo-session-manager) kills
it as part of an orderly logout.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>