On Mon, Apr 14, 2025, 17:20 Jeremy Su <os369...@gmail.com> wrote: > Hi Mantas, > > Thank you for your reply. > > > Mantas Mikulėnas <graw...@gmail.com> 於 2025年4月14日 週一 下午5:58寫道： > > > > On Fri, Apr 11, 2025 at 4:14 PM Jeremy Su <os369...@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 >
