On Fri, 08 Mar 2024 at 10:22:50 +0300, Andrei Borzenkov wrote:
> Restarting D-Bus was never safe and never supported. Every individual
> application would need to support D-Bus connection loss and be able to
> transparently reconnect.
None of the client libraries implement this; and if they did, they
would have missed messages during the downtime, which would require
application-specific state recovery which is only possible at the
application level. For example, taking NetworkManager as an arbitrary
example of a D-Bus service: a NetworkManager client like GNOME Shell needs
to do NetworkManager-specific things to "catch up" with any messages that
it missed, and it is not possible to do that generically in a D-Bus client
library without knowing things that are specific to NetworkManager.
> I do not know if D-Bus daemon keeps any internal
> state that would need restoring as well.
Yes, it certainly does keep internal state. I'm pretty sure it isn't
possible to implement the message bus interface without keeping a
significant amount of state.
Being able to restart the message bus safely would require being able to
serialize internal state, store it somewhere (perhaps a file or systemd),
hand off the AF_UNIX sockets to systemd, restart, get the sockets back,
deserialize the state and carry on. I am not aware of any implementations
of that being attempted in D-Bus' 20 year history, and it would be a
relatively large amount of rarely-tested (and therefore buggy) code.
If you are restarting the message bus on a live system, it is most likely
to be because it has a bug or a security vulnerability that you want
fixed; but if that's the case, then the serialized state would need
to be treated as at least partially untrusted, which only makes that
task harder.
(I'm mainly thinking of dbus-daemon here, but I don't see how the
situation could be significantly different for other message bus
implementations like dbus-broker - any message bus is implementing the
same specification, so it needs the same amount of internal state in
order to do its job.)
smcv
