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

[Mantas Mikulėnas]

On Mon, Apr 14, 2025, 17:20 Jeremy Su <os369510 at gmail.com> wrote:

> 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?
>

No, it's kind of the opposite of socket activation.

*Normal* D-Bus service activation (the 'activatable' in busctl, like when
you run 'timedatectl' and systemd-timedated launches automatically) is like
socket activation; but what resolved does with inotify when it starts
before D-Bus is the opposite of that.

>
> > 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) -                          -       -
>

That's the status of resolved on the D-Bus system bus – not related to its
private socket status.

The private socket is in /run/systemd/resolve, you can use `ls -l` to check
for its existence.

It uses a different protocol (varlink rather than D-Bus), use varlinkctl to
poke at it:

$ varlinkctl info /run/systemd/resolve/io.systemd.Resolve
$ varlinkctl introspect /run/systemd/resolve/io.systemd.Resolve
io.systemd.Resolve


>
> 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?
>

Yes, for programs that use the non-D-Bus-based methods. So if something
calls getaddrinfo() to resolve a hostname and goes through libnss_resolve,
then – in modern systemd versions – it will contact
/run/systemd/resolve/io.systemd.Resolve without any dependency on the
system bus.

(With older systemd versions, though, this *would* have required D-Bus to
be up.)

The programs which directly talk to resolved via D-Bus would still have to
wait (but generally that's not an issue; probably all such programs would
start well after basic.target anyway).


>
>
> --
> Sincerely,
> Jeremy Su
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250414/27c574a2/attachment-0001.htm>