[systemd-devel] The dependencies between systemd-resolved and dbus.socket

[Jeremy Su]

Hi Mantas,

Thank you for your reply.


Mantas Mikulėnas <grawity at gmail.com> 於 2025年4月14日 週一 下午5:58寫道：
>
> On Fri, Apr 11, 2025 at 4:14 PM Jeremy Su <os369510 at gmail.com> wrote:
>>
>> Hi,
>>
>> I meet a problem that systemd-resolved is not able to resolve the DNS.
>>
>> systemd-resolved[1237]: sd-bus: starting bus bus-api-resolve by connecting to /run/dbus/system_bus_socket...
>> systemd-resolved[1237]: Added inotify watch for /run on bus bus-api-resolve: 2
>> systemd-resolved[1237]: Added inotify watch for /run/dbus on bus bus-api-resolve: 3
>> systemd-resolved[1237]: Added inotify watch for /run/dbus/system_bus_socket on bus bus-api-resolve: -1
>> systemd-resolved[1237]: sd-bus: starting bus bus-api-resolve by connecting to /run/dbus/system_bus_socket...
>>
>> It seems to me that the systemd-resolved doesn't able to access /run/dbus/system_bus_socket. FWIU, the /run/dbus/system_bus_socket is created by dbus.socket.
>>
>> However, the dependencies seem like:
>>
>> systemd-resolved -> sysinit.target -> dbus.socket.
>>
>> according to:
>>
>> $ systemctl show dbus.socket | grep -i after
>> After=-.mount sysinit.target system.slice
>>
>> $ systemctl show systemd-resolved | grep -i before
>> Before=initrd-switch-root.target shutdown.target nss-lookup.target network.target sysinit.target
>>
>> If I set "Wants=dbus.socket" "Before=dbus.socket" in systemd-resolved, then it'll introduce circular dependency.
>
>
> It's a known issue with D-Bus being the way it is, and that's the whole purpose of the inotify watch: sd-bus is *watching for the socket to appear* so that resolved could start before the system bus does, and then connect to the bus as soon as the socket is created.

Guess it's something like socket activation?
>
> Systemd-resolved still offers services either through DNS at 127.0.0.53, or through a direct Unix socket – in current versions, libnss_resolve communicates with resolved through a direct socket instead of using the system bus, so the dependency on dbus.socket isn't as important.
>

I was checking the socket status:

NAME                                 PID PROCESS         USER
CONNECTION    UNIT                       SESSION DESCRIPTION
...
org.freedesktop.resolve1               - -               -
(activatable) -                          -       -

When I restart the systemd-resolve, it shows:

org.freedesktop.resolve1              493 systemd-resolve
systemd-resolve      :1.0          systemd-resolved.service
    -       -

Do you mean the systemd-resolved should work even if dbus.socket is not started?



-- 
Sincerely,
Jeremy Su