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

Umut Tezduyar Lindskog <umut-v3uyoVUDKFtWk0Htik3J/[email protected]>
Newsgroups gmane.comp.freedesktop.dbus
Message-ID <CAFKnvs6D3=02+AxigPA0RSjL4WBa8TJ-DemR82nJgx2x004eUA@mail.gmail.com>
On Tue, Apr 5, 2016 at 8:10 PM, Zizka, Jan (Nokia - CZ/Prague)
<[email protected]> 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
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/dbus
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.