On Tue, 19 May 2020 at 10:31, Arian Van Putten <[email protected]> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
