[systemd-devel] What is the point of making timesyncd bus-activatible?

[Dimitri John Ledkov]

On Tue, 19 May 2020 at 10:31, Arian Van Putten <arian at wire.com> 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.