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