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

Umut Tezduyar Lindskog umut at tezduyar.com
Tue Apr 12 11:39:49 UTC 2016


On Tue, Apr 5, 2016 at 8:10 PM, Zizka, Jan (Nokia - CZ/Prague)
<jan.zizka at nokia.com> wrote:
>> dbus-daemon does not support restarting without losing all
>> connections, and the dbus protocol does not define any logic to
>> recover from closed connections. Thus dbus-daemon is considered a
>> daemon that cannot be restarted. The code is a bit like the kernel in
>> that regard, which requires a full reboot to be updated.
>
> Thanks Lennart, I don't know much about dbus-daemon internals :).
>
> Would it then make sense to configure dbus.service to trigger system reboot
> right away? Somethink like:
>
> FailureAction=reboot
>
> But that won't catch cases when dbus-daemon would exit successfully. Hmm I didn't
> figure out any simple way to achieve that.
>
> Would you have any ideas how to handle this with systemd?

Alternatively you can implement a patch to support gaining connections
back if dbus upstream is OK with it. There are 2 challenges. First,
just keeping the connections up. You can use systemd to keep an eye on
the connections while you are restarting. The API is sd_notify
(https://www.freedesktop.org/software/systemd/man/sd_notify.html).
Journald does this. Even if the journald gets killed, connections with
services with journald connection are not terminated. Second is the
keeping track of dbus connection states. Somehow you need to
serialize-desirealize connection states between reboots.

Umut

>
> Regards
>
> Jan
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dbus


More information about the dbus mailing list