units: start systemd-resolved in basic.target

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
index 00812fb26c9085168f3481721486740a285b946e..dfe82e1e4d884e977a9c4a17c5c35c23f01de84f 100644 (file)
--- 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