<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Apr 14, 2025, 17:20 Jeremy Su <<a href="mailto:os369510@gmail.com">os369510@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Mantas,<br>
<br>
Thank you for your reply.<br>
<br>
<br>
Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank" rel="noreferrer">grawity@gmail.com</a>> 於 2025年4月14日 週一 下午5:58寫道：<br>
><br>
> On Fri, Apr 11, 2025 at 4:14 PM Jeremy Su <<a href="mailto:os369510@gmail.com" target="_blank" rel="noreferrer">os369510@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I meet a problem that systemd-resolved is not able to resolve the DNS.<br>
>><br>
>> systemd-resolved[1237]: sd-bus: starting bus bus-api-resolve by connecting to /run/dbus/system_bus_socket...<br>
>> systemd-resolved[1237]: Added inotify watch for /run on bus bus-api-resolve: 2<br>
>> systemd-resolved[1237]: Added inotify watch for /run/dbus on bus bus-api-resolve: 3<br>
>> systemd-resolved[1237]: Added inotify watch for /run/dbus/system_bus_socket on bus bus-api-resolve: -1<br>
>> systemd-resolved[1237]: sd-bus: starting bus bus-api-resolve by connecting to /run/dbus/system_bus_socket...<br>
>><br>
>> 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.<br>
>><br>
>> However, the dependencies seem like:<br>
>><br>
>> systemd-resolved -> sysinit.target -> dbus.socket.<br>
>><br>
>> according to:<br>
>><br>
>> $ systemctl show dbus.socket | grep -i after<br>
>> After=-.mount sysinit.target system.slice<br>
>><br>
>> $ systemctl show systemd-resolved | grep -i before<br>
>> Before=initrd-switch-root.target shutdown.target nss-lookup.target network.target sysinit.target<br>
>><br>
>> If I set "Wants=dbus.socket" "Before=dbus.socket" in systemd-resolved, then it'll introduce circular dependency.<br>
><br>
><br>
> 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.<br>
<br>
Guess it's something like socket activation?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No, it's kind of the opposite of socket activation.</div><div dir="auto"><br></div><div dir="auto">*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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> 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.<br>
><br>
<br>
I was checking the socket status:<br>
<br>
NAME                                 PID PROCESS         USER<br>
CONNECTION    UNIT                       SESSION DESCRIPTION<br>
...<br>
org.freedesktop.resolve1               - -               -<br>
(activatable) -                          -       -<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That's the status of resolved on the D-Bus system bus – not related to its private socket status.</div><div dir="auto"><br></div><div dir="auto">The private socket is in /run/systemd/resolve, you can use `ls -l` to check for its existence.</div><div dir="auto"><br></div><div dir="auto">It uses a different protocol (varlink rather than D-Bus), use varlinkctl to poke at it:</div><div dir="auto"><br></div><div dir="auto">$ varlinkctl info /run/systemd/resolve/io.systemd.Resolve</div><div dir="auto">$ varlinkctl introspect /run/systemd/resolve/io.systemd.Resolve io.systemd.Resolve</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>
When I restart the systemd-resolve, it shows:<br>
<br>
org.freedesktop.resolve1              493 systemd-resolve<br>
systemd-resolve      :1.0          systemd-resolved.service<br>
    -       -<br>
<br>
Do you mean the systemd-resolved should work even if dbus.socket is not started?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">(With older systemd versions, though, this *would* have required D-Bus to be up.)</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
-- <br>
Sincerely,<br>
Jeremy Su<br>
</blockquote></div></div></div>