On Sun, 12 Jan 2025 18:40:56 +0100 Gioele Barabucci <[email protected]>
wrote:
Please find attached a log (from `sudo journal`, on a system booted with
`systemd.log_level=debug`) displaying the issue.
The log starts just before systemd-resolved is installed and includes
one usage of `resolvectl status`.
This bug is probably exposing a race condition between sd-resolved
trying to establish a DBUS service and DBUS being reloaded with the
required policy in place.
Slightly edited snippet of an IRC conversation on #debian-mentors:
<dwfreed> I'm guessing that the order of operations is wrong
<gioele> you can play with
https://people.debian.org/~gioele/sd-resolved-1092805.qcow2 if you want
to dig deeper, it is a snapshot of a tiny VM frozen just before
installing sd-resolved
<gioele> I think this issue is part of a more general problem related to
the way dbus services (sd-resolved in this case) are installed and made
available just after installation
<dwfreed> indeed, dbus probably needs to be reloaded before the service
is started generally, not just specifically for systemd-resolved
<dwfreed> it probably works out okay for most services much of the time
because they take "forever" to start up, whereas resolved basically
opens the dbus connection immediately, but it's still a bad race condition
<dwfreed> perhaps debhelper could get an automatic postinst snippet that
forces a dbus reload if a package installs dbus config files, rather
than relying on the trigger
<dwfreed> (and ensure that's ordered before any dh_installsystemd snippets)
--
Gioele Barabucci
