Bug#1092805: resolvectl status times out after installation

Gioele Barabucci gioele at svario.it
Sun May 25 20:29:14 BST 2025


On Sun, 12 Jan 2025 18:40:56 +0100 Gioele Barabucci <gioele at svario.it> 
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



More information about the Pkg-systemd-maintainers mailing list