Re: .service and .socket

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 01.01.19 13:46, Olaf van der Spek (ml@xxxxxxxxxx) wrote:

> Hi,
>
> AFAIK socket units require a separate file, which seems more complex
> then it has to be.

The main reason why socket and service units are separate is that this
way they may be separately scheduled. i.e. a socket can be established
early and only when it is triggered the matching service is pulled in
with all its dependencies which might delay its activation. The socket
hence can have entirely different dependencies, properties, timings,
lifecycles than the activated services, and that's a *good* thing.

> 1. Could sockets be specified directly in the .service file?

This has been suggested before, but the ability to schedule sockets
and services independently from each other is kinda crucial (it's
pretty much what allows us to put together the whole boot process from
units, unlike for example launchd-based systems where socket
activation is suitable only for "regular" services, but not
permissible for early boot).

We could of course add redundancy here, and allow socket activation
both with embedded information in service unit files (as you suggest)
and with separate socket and service unit files (as is implemented
right now), but quite frankly this kind of redundancy just complicates
things further... Everything comes at the price. And when the goal is
simplification then adding redundancy and thus complexity is
very problematic.

I mean, I am all for changing and simplifying things, and even if this
creates temporary redundancy, but it has to stay temporary, i.e. there
needs to be a clear path to a new scheme that can cover the old scheme
too, so that the old scheme doesn't have to stay around. But this is
not the case here, as the current scheme is substantially more
powerful than what you suggest, if you follow what I mean...

> 2. If not, could the .service file gain a default / implicit
> dependency on the .socket file?

Well, there are services that are socket-activatable and services
which are not. We'd have to determine that before we could add such a
dep, but that determination is problematic and not how systemd works
right now. Moreover there are services which have two sockets assigned
to them, and neither is called like the service itself. For example,
systemd-udevd.service is activated through the pair
systemd-udevd-control.socket and systemd-udevd-kernel.socket but there
is no systemd-udevd.socket.

> 3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper default?

I am not grokking this one?

What you are proposing has been requested before (well, 1 + 2, I don't
understand 3), and I very much sympathize with it, and in fact is how
the design started out when we began with systemd, but I don't see how
such a scheme could cover the same ground in a nice way, without
appearing too redundant...

Lennart

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