On Wed, 28 Jun 2023 at 01:50:07 +0000, Thorsten Glaser wrote:
> Setting up dbus (1.12.28-0+deb11u1) ...
> A reboot is required to replace the running dbus-daemon.
> Please reboot the system when convenient.
>
> I read through the bugreport and I can see why it should not
> just be automatically restarted.
This has been discussed at *extensive* length before, and I'm pretty
sure nothing I say is going to change your opinion anyway, but OK,
let's do this one more time.
I should start by saying that none of this is new, and none of this was
my idea: what I describe here has been how D-Bus is designed to work for
at least 15 years, more like 20, considerably pre-dating my involvement
in it. I'm constrained by compatibility just as much as anyone else is.
Restarting the system dbus-daemon, `dbus-daemon --system`, on a running
system is not a supported action. It disconnects all system-level D-Bus
clients and services, which nearly always causes them to exit. Of the
major protocol implementations, libdbus calls exit() unless told not to;
GDBus does a raise(SIGTERM) unless told not to, which with hindsight is
a better route to take because long-running processes need to cope with
being sent SIGTERM anyway, either exiting immediately from its default
handling or triggering whatever cleanup they need; and I don't immediately
know what sd-bus does.
Exiting on disconenction by default is very much intentional here. If
they didn't exit, and even if they automatically reconnected (which in
practice none do), then D-Bus clients would lose track of the state
of the services they are communicating with (because they would have
missed an unknown number of change-notification signal messages while
they were reconnecting). For well-designed D-Bus services, the clients
would need domain-specific knowledge of how to do state-recovery by
calling methods to ask the service "sorry, I got disconnected, what is
the state of the world now?", which is a code path that would be rarely
tested and therefore in practice often wouldn't work; and they would
also need to be careful not to take any actions with side-effects based
on potentially outdated information while they were catching up with
the current state of the world.
For less well-designed D-Bus services, state recovery is not always
even implementable, because API designers haven't always thought about
it. (Obviously you should use well-designed services if you can, but
sometimes those are not what's available.)
I've said "clients" and "services" as a simplification, but as far as
the design of D-Bus is concerned, they are all just peers - many services
that use D-Bus to provide functionality to other processes are also a
client of a "smaller" service - so anything that is necessary for clients
is also necessary for services.
Restarting the session dbus-daemon, `dbus-daemon --session`, in a
running login session is similarly not a supported action. It disconnects
all session-level (per-login or per-user) D-Bus clients and services,
similar to what happens on the system bus.
On the session bus, as well as the practical concerns above, the design
is that being disconnected from the session bus is the way that non-GUI
processes are notified that the session has ended, so if they did not
exit when disconnected (either immediately or after doing some cleanup),
they would continue to run after your login session was ended; and instead
of bug reports about how you think the dbus-daemon should restart itself
on upgrade, you'd be opening bug reports about how some random session
service (one that doesn't use X11 itself, like dconf or gnome-keyring)
isn't exiting as you want it to when you log out from an X11 session.
Having background session services exit deterministically when the session
ends was one of the original (circa 2002) design goals of D-Bus.
Compare with any other stateful IPC protocol, like X11. In principle, it
is possible to write an X11 client that can reconnect when you restart the
X11 server. In practice, essentially nobody does (I think Emacs might?)
because it's difficult to do correctly; and arguably it's a bug to try,
because being disconnected from the X11 server is the way that graphical
applications are told "the session is over, it's time to exit".
My earlier messages to this bug talk about handing off IPC connections
across a re-exec. In principle, there would be nothing to stop Someone™
from making it possible to restart the dbus-daemon without disconnecting
all of the connected processes, by serializing the entire state of the
dbus-daemon, fd-passing all of its connections to some helper process,
re-exec'ing itself, reading the serialized state back in, receiving
the conection fds back from the helper process and carrying on. systemd
does the equivalent thing for its state and its (intentionally simpler)
IPC protocols.
I am not aware of anyone having ever seriously attempted this for D-Bus
(or for X11, which would likely have comparable complexity). Even
if someone stepped up to do that, reviewing that implementation for
correctness (and/or fixing the inevitable CVEs when it turned out not
to be perfect) would take a significant amount of maintainer time that,
to be blunt, I just don't have.
> But I could just restart dbus and then all things that use it.
You can do this if you are confident that you understand what will happen,
but it is an unsupported action and I will not help you to do so.
On a typical Debian system, restarting `dbus-daemon --system` will
cause system services to stop working, in a way that is only practical
to recover from by a reboot. If you have an in-depth understanding of
all the components on your system that use D-Bus, then I'm sure you can
figure out how to identify and restart them manually in the correct order,
but that is not a supported or supportable thing to do.
Similarly, in general restarting `dbus-daemon --session` will cause
parts of your X11 (or Wayland) session to stop working, in a way that
is only practical to recover from by logging out and back in.
Both of these would be extremely disruptive, and dbus-daemon would
(correctly!) receive critical-severity bug reports if we tried to do
this automatically, so we don't.
> This is a systemd-free shop, so… I don’t even know what would
> use dbus at all.
D-Bus is about 8 years older than systemd, and many things that are
not systemd use it. I don't know what all of them are, in the same way
that the maintainers of Xorg would be unable to give you a comprehensive
list of all the X11 applications that exist.
> Is there a “needrestart”-like tool, or something like ps/netstat,
> showing which programs use dbus, for restarting them afterwards?
The D-Bus protocol operates over an AF_UNIX socket (a lot like X11 and
Wayland), so passing suitable options to netstat or ss will tell you
what is connected to it.
smcv
_______________________________________________
Pkg-utopia-maintainers mailing list
Pkg-utopia-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
