Re: Please stop hating on sysvinit
Vincent Bernat - 09.08.19, 07:00:41 CEST:
> ❦ 8 août 2019 21:47 +02, Simon Richter <sjr@debian.org>:
> >> inetd performance is very low because it needs to spawn one
> >> instance for each connection. systemd socket activation has
> >> absolutely 0 overhead except on the first connection (where
> >> systemd needs to start the service).
> >
> > If you specify "wait" instead of "nowait" for a TCP service, your
> > service is handed the listening socket, and can continue to accept
> > more connections on that socket.
[…]
> > This feature went unused not because noone thought of it, but
> > because there is no real world use case that benefits from it.
> > Either the service is used regularly, then it makes sense to keep
> > the daemon in memory, or it isn't, then the reduced complexity for
> > one-shot services (to the point where you can use a shell script as
> > a service) is the benefit.
>
> Reality seems different. Almost nothing was using inetd (tftpd is the
I note that you wrote "seems". But still:
As if there would just be *one* reality. Actually there is. But I never
saw any human being being able to express it in words. So I'd rather
not. I believe it can be experienced at any time. But for me it is
beyond words and so much else.
With arguing about what reality might be and claiming it is this or
such… the trouble starts. Cause then people who somehow dare to manage
to experience a different reality can easily be made wrong. I think this
has been one of the core issues around the conflicts regarding Systemd.
How dare you see things different than me? But you just need to talk to
ten people to recall a situation they experienced together and you will
receive ten different story. Now: which one would be right?
What if, just what if all of what we are talking about is completely
arbitrary? What if, just what if no one is actually right or wrong here?
> only daemon I have in mind), while many daemons adopted systemd socket
> activation. For example, OpenSSH (optional), Docker (by default),
> CUPS (by default), libvirt (by default, several services), Dovecot
> (by default). It seems the key difference is that socket-activated
> services are regular services. They can be started manually if we
> want them to be and they inherit everything systemd is able to
> provide to services.
For Dovecot I can say from first hand experience that it only uses socket
activation when Systemd is actually available. My main server which also
does mail uses Sysvinit meanwhile and Dovecot, Postfix and other services
work just fine.
And, heck… it is a mail server… so I do not mind the processes running
24/7. They consume only little resources and even less resources when
they are idle.
Actually as a user of my services I do not even notice any difference, so
for me it is: What is actually the point of starting them on demand? I
just have no use of the added complexity. It does not give me any
visible benefit, it does not give me any benefit I can actually
experience. So I just *don't* care. I just tend to happen a preference
for simplicity.
Also as neither Dovecot nor Postfix tend to suddenly stop operating
suddenly, there is not point into automatically restarting them either.
If one of the processes exit uncleanly, I like to know it. Of course I
can monitor it, but why actually? I will notice when mail is not
available soon enough.
For my use case thus it is:
Make it as simple as possible, but not simpler.
Of course when you run things in containers and cloud environment socket
activation might make all of the difference. But that is not how I intend
to run things. I may use a container for Nextcloud… but on the other
hand I say: If I do not trust Nextcloud would be secure enough… why run
it anyway? Especially as the packaging situation around Nextcloud is… a…
mess… from what I saw. And I just do not like to use anything other than
packages I can install with apt on a server.
--
Martin
Reply to: