On Tue, 19 May 2020 at 10:31, Arian Van Putten <arian@xxxxxxxx> wrote: > > Hey list, > > systemd-timesyncd has an Alias=dbus-org.freedesktop.timesync1.service and an accompanying dbus service file too. > > It is started in early boot; `Before=sysinit.target` so why would making it dubs-activatible ever make sense? It is always started way before dbus.service itself is started. > > It also seems that the unit type is not Type=dbus (and doesn't set a BusName) which confuses me a bit. So maybe I'm misunderstanding how dbus integration works here. Ist that because we want to consider the services "ready" before they even register a name on the bus? > > Similarly systemd-resolved.service and systemd-networkd.service have such aliases whilst they're both pulled in by `multi-user.target` and also do not have `Type=dbus` and `BusName=` set. > > What are the reasons for that? For resolve1 i guess it makes sense as you dont have to think about ordering when making dns calls in services. But I am still confused why it is not of Type=dbus. Is that because it not only gives a dbus API but also a DNS api? > it serves requests on 127.0.0.53 and provides dynamic files generated in /run/systemd/resolve/ which can be targets of /etc/resolv.conf symlink. Hence even without anything talking to it over dbus or lo interface, it can be serving information to the system. I.e. it populates both /run/systemd/resolve/resolv.conf and /run/systemd/resolve/stub-resolv.conf either of which can be symlinked to /etc/resolv.conf for nss modules to use. -- Regards, Dimitri. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel