Re: What is the point of making timesyncd bus-activatible?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 19.05.20 11:30, Arian Van Putten (arian@xxxxxxxx) wrote:

> Hey list,

Sorry for the late response, this somehow managed to escape me.

> 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?

Providing bus activation for early-boot services has the benefit that
it removes a bus name race when dbus-daemon/dbus-broker itself is
eventually invoked.

Early boot services that want to offer services via the bus, generally
create their bus connections with sd_bus_set_watch_bind() configured
(see man page for details), so that their bus connections are
allocated during early boot, but are only actually connected the
moment dbus.socket is bound and thus the socket becomes connectible,
which might be much later. They also should provide activation files
for dbus-daemon/dbus-broker, so that the names they eventually want to
take via their connections are reserved right from the first moment
dbus-daemon/dbus-broker actually starts running. To reserve them that
early has the benefit that any client can immediately start talking to
these services via the bus, without any further synchronization
(i.e. without waiting for the bus names to be actually taken). That's
because D-Bus activation means that some service is started and while
that happens all messages to that service are queued until that
service is up which opens the floodgates and flushes out all those
queued messages to them.

So, key about providing this activation files is *not* the fact that
they activate the services behind them (I mean, they do, but that's
not interesting since the services are running anyway, long before
dbus-daemon/dbus-broker, so starting them is a redundant NOP), but the
fact that all messages are queued for them, until they manage to
finish their connection start-up.

Does this matter? Yes, it does: after all we start as much as we can
in parallel as early as possible. that means the instand dbus.socket
is bound half the system tries to connect to the bus and it's not
clear which connections win, and are established early, and which ones
lose and succeed later. If one if the early ones starts talking to the
late one before the late ones are connected without this actvation
logic described above they'd get "No such service" back.

Makes sense?

> 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.

So, Type=dbus/BusName= is about ready notification, which is not
related to activation. It's totally ok to be bus activated and to do
ready notification in a different way. In fact, it's not just OK, but
it's a *good* thing in many cases even, specifically when we are
talking about early-boot stuff: since dbus-daemon/dbus-broker isn't up
then we can't use it for ready notifcation.

So yeah, early boot bus services should:

1. not use Type=dbus, but Type=notify or so
2. should use sd_bus_set_watch_bind() for their bus connection
3. should provide a dbus activation file

And then everything is race-free and robust.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel