Dear systemd maintainers,

on a fresh Debian 12.9 installation, `resolvectl` is not usable out of
the box.

Sometimes `resolvectl status` fails with "Failed to get global data:
Connection timed out", sometimes with "Failed to get global data: Failed
to activate service 'org.freedesktop.resolve1': timed out
(service_start_timeout=25000ms)".

Restarting dbus does not solve this issue.

Restarting systemd-resolved solves this issue.

Slightly abridged log:

tester@debian:~$ sudo apt install systemd-resolved
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
   polkitd | policykit-1
Recommended packages:
   libnss-myhostname libnss-resolve
The following NEW packages will be installed:
   systemd-resolved
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 307 kB of archives.
After this operation, 833 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bookworm/main amd64 systemd-resolved
amd64 252.33-1~deb12u1 [307 kB]
Fetched 307 kB in 0s (2442 kB/s)
Selecting previously unselected package systemd-resolved.
(Reading database ... 20513 files and directories currently installed.)
Preparing to unpack .../systemd-resolved_252.33-1~deb12u1_amd64.deb ...
Unpacking systemd-resolved (252.33-1~deb12u1) ...
Setting up systemd-resolved (252.33-1~deb12u1) ...
Converting /etc/resolv.conf to a symlink to
/run/systemd/resolve/stub-resolv.conf...
Creating group 'systemd-resolve' with GID 996.
Creating user 'systemd-resolve' (systemd Resolver) with UID 996 and GID 996.
Created symlink
/etc/systemd/system/dbus-org.freedesktop.resolve1.service →
/lib/systemd/system/systemd-resolved.service.
Created symlink
/etc/systemd/system/sysinit.target.wants/systemd-resolved.service →
/lib/systemd/system/systemd-resolved.service.
Processing triggers for dbus (1.14.10-1~deb12u1) ...

tester@debian:~$ systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
      Loaded: loaded (/lib/systemd/system/systemd-resolved.service;
enabled; preset: enabled)
      Active: active (running) since Sat 2025-01-11 20:17:10 CET; 1min
52s ago
        Docs: man:systemd-resolved.service(8)
              man:org.freedesktop.resolve1(5)
    Main PID: 480 (systemd-resolve)
      Status: "Processing requests..."
       Tasks: 1 (limit: 1141)
      Memory: 3.7M
         CPU: 62ms
      CGroup: /system.slice/systemd-resolved.service
              └─480 /lib/systemd/systemd-resolved

tester@debian:~$ resolvectl status
Failed to get global data: Connection timed out

tester@debian:~$ sudo systemctl restart systemd-resolved.service

tester@debian:~$ resolvectl status
Global
        Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens3)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
      Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
                 DNSSEC=no/unsupported
    DNS Servers: 192.168.120.1

tester@debian:~$ sudo journalctl -u systemd-resolved
Jan 11 20:17:09 debian systemd[1]: Starting systemd-resolved.service -
Network Name Resolution...
Jan 11 20:17:10 debian systemd-resolved[480]: Positive Trust Anchors:
Jan 11 20:17:10 debian systemd-resolved[480]: . IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e>
Jan 11 20:17:10 debian systemd-resolved[480]: Negative trust anchors:
home.arpa 10.in-addr.arpa 16.>
Jan 11 20:17:10 debian systemd-resolved[480]: Using system hostname
'debian'.
Jan 11 20:17:10 debian systemd[1]: Started systemd-resolved.service -
Network Name Resolution.
Jan 11 20:27:47 debian systemd[1]: Stopping systemd-resolved.service -
Network Name Resolution...
Jan 11 20:27:47 debian systemd[1]: systemd-resolved.service: Deactivated
successfully.
Jan 11 20:27:47 debian systemd[1]: Stopped systemd-resolved.service -
Network Name Resolution.
Jan 11 20:27:47 debian systemd[1]: Starting systemd-resolved.service -
Network Name Resolution...
Jan 11 20:27:47 debian systemd-resolved[647]: Positive Trust Anchors:
Jan 11 20:27:47 debian systemd-resolved[647]: . IN DS 20326 8 2
e06d44b80b8f1d39a95c0b0d7c65d08458e>
Jan 11 20:27:47 debian systemd-resolved[647]: Negative trust anchors:
home.arpa 10.in-addr.arpa 16.>
Jan 11 20:27:47 debian systemd-resolved[647]: Using system hostname
'debian'.
Jan 11 20:27:47 debian systemd[1]: Started systemd-resolved.service -
Network Name Resolution.


Regards,

As requested on IRC:

$ busctl --system | grep resolve
org.freedesktop.resolve1  - - - (activatable) - - -

Regards,

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`.

Regards,

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)