units: start systemd-resolved in basic.target

keszybz · keszybz · commit 79a67f3ca4d3 · 2022-01-09T20:03:22.000+01:00
In the olden days systemd-resolved used dbus and it didn't make sense to start it before dbus which is started fairly late. But we have mostly ported resolved over to varlink. The queries from nss-resolve are done using varlink, so name resolution can work without dbus. resolvectl still uses dbus, so e.g. 'resolvectl query' will not work, but by starting systemd-resolved earlier we're not making this any worse. If systemd-resolved is started after dbus, it registers the name and everything is fine. If it is started before dbus, it'll watch for the dbus socket and connect later. So it should be fine to start systemd-resolved earlier. (If dbus is stopped and restarted, unfortunately systemd-resolved does not reconnect. This seems to be a small bug: since our daemons know how to watch for dbus.socket, they could restart the watch if they ever lose the connection. But this scenario shouldn't happen in normal boot, and restarting dbus is not supported anyway.) Moving the start earlier the following advantages: - name resolution becomes availabe earlier, in particular for synthesized hostnames even before the network is up. - basic.target is part of initrd.target, so systemd-resolved will get started in the initrd if installed. This is required for nfs-root when the server is specified using a name (https://bugzilla.redhat.com/show_bug.cgi?id=2037311).
diff --git a/units/systemd-resolved.service.in b/units/systemd-resolved.service.in
@@ -54,5 +54,5 @@ User=systemd-resolve
 {{SERVICE_WATCHDOG}}
 
 [Install]
-WantedBy=multi-user.target
+WantedBy=basic.target
 Alias=dbus-org.freedesktop.resolve1.service
