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