[systemd-devel] .service and .socket

[Lennart Poettering]

On Mi, 02.01.19 11:38, Olaf van der Spek (ml at vdspek.org) wrote:

> > 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...
>
> I'm not proposing removing the current scheme.
> The new scheme might / would increase systemd (code) complexity but
> it'd simplify end-user / conf / service / socket files.
> I agree is't not a perfect improvement (simplifying both) but it might
> still be worth it.

Well, but that's the redundancy I am talking about: we'd then have two
schemes to support for perpetuity in parallel, and that's not what I
am too fond of...

it boils down to the question, what is better:

1. just two short unit files

2. supporting a pair of two short unit files +
   supporting a single, longer unit file with some new additional
   decoration that clarifies which object let's say a setting like
   "After=" applies to (which is a setting after all which might be
   used for the socket or for the service, and in both cases valid).

I think I prefer the simplicity of #1 in this case...

Moreover, consider the unit list "systemctl" shows you when you invoke
it. Right now, it's relatively easy to figure out the relationship
between the units listed there and the unit files on disk: they mostly
map 1:1: the unit name is the file name. (within bounds, admittedly,
think templates/instances). This is a really nice property. If we'd
now allow embedding both socket and service bits into the same file,
then we'd lose that, and unit names and unit file names would start to
deviate...

> > > 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.
>
> I don't follow. If they're not, would they have a .socket file?

No, but this would have to be detected. This would mean when we load a
.service we'd always have to look for any matching .socket file, and
then add an implicit dep if it exists, and none if it doesn't.

> > 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.
>
> In that case the automatic dependency of course wouldn't be added.

But this is kinda nasty to implement, because this means we'd not only
have to search for <foo>.socket if <foo>.service is loaded but also
for basically *.socket to see if any of the socket files lists
Service=<foo>.service in it...

That would certainly be doable, but it would reverse how systemd loads
units right now. Right now it loads things lazily: only units that are
explicitly referenced are loaded, and units that are never referenced
are not, i.e. systemd doesn't load *everything* that is in
/usr/lib/systemd/system/*, but just the stuff default.target pulls in
directly and indirectly, and then adds in whatever else is
needed. This scheme is kinda nice, since it means template schemes
nicely fit into it: we can search for a matching unit template file
when a specific unit instance is requested. If we'd load everything in
advance otoh, then this could never cover templates/instances, as
during runtime any kind of instance can appear, and this always means
we need to start searching, if you follow what I mean...

Lennart

--
Lennart Poettering, Red Hat