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

[Zizka, Jan (Nokia - CZ/Prague)]

> From: dbus [mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of EXT Simon McVittie
> Sent: Monday, April 11, 2016 1:16 PM
>
> 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)

I definately agree with all these points. I forgot to mention that system I'm working on
is 5 9s and didn't realize that for general-purpose computers this would do more harm
then good. 

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

This is great idea, I have totally missed the drop-in config overriding in systemd.
Thanks for pointing this out.

Jan Zizka