[systemd-devel] .service and .socket

[Olaf van der Spek]

On Wed, Jan 2, 2019 at 11:05 AM Lennart Poettering
<lennart at poettering.net> wrote:
>
> On Di, 01.01.19 13:46, Olaf van der Spek (ml at vdspek.org) wrote:
> 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...

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.

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

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

> > 3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper default?
>
> I am not grokking this one?

It's entirely separate from 1 and 2, I should've put it in another email.

-- 
Olaf