Vincent Bernat - 09.08.19, 07:00:41 CEST: > ❦ 8 août 2019 21:47 +02, Simon Richter <s...@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
