Which init system for Debian?

Posted Nov 16, 2013 0:45 UTC (Sat) by anselm (subscriber, #2796)
In reply to: Which init system for Debian? by khim
Parent article: Which init system for Debian?

That is not the business xinetd is in, so it's no big surprise that it can't do it (anymore than it can shine shoes and make coffee).

The problem seems to be that there appear to be several definitions around of what »socket activation« actually means. Inetd/xinetd listen to a socket, and if a connection request comes in they start the daemon in question, which handles the request and then quits. The next connection request causes another instance of the daemon to be started. This of course is terribly inefficient for the kind of service such as HTTP that is not based on long-running sessions, and not especially efficient for services that are, like FTP or SMTP.

Systemd can do this, too, but it also supports a different kind of socket activation where the first connection request causes the daemon to be launched, and then instead of quitting after the request has been handled, the daemon just keeps running to handle any further requests (with no more overhead for extra startups). This is very convenient but inetd/xinetd simply don't do it. Possibly nix knows about some tool based on SysV init that can do that sort of thing, but if it does exist it is certainly not anywhere near mainstream on Linux.

Which init system for Debian?

Posted Nov 16, 2013 6:44 UTC (Sat) by spaetz (guest, #32870) [Link]

anselm, xinetd can indeed start a service on first demand AND keep it running for allsubsequent requests. Check out Lennart's post if you don't believe me :-) .

xinetd might be a bicycle, but it does have electric motor and 21 gears...

Which init system for Debian?

Posted Nov 16, 2013 17:57 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

*Sigh* There are two way to "socket-activate" a process.

All start by actually opening a socket and listen()ing to it. When a connection request arrives,

(a) accept the connection, start a new server, hand the new connection to it on stdin/out. This is, in general, not a good idea because you pay the startup cost for every request.

(b) DO NOT accept the connection; instead, start a new server, hand the listening socket to the server (typically on stdin). Ignore the socket until the server dies. (x)inetd, systemd, upstart, … all can do this.

The condition "the server dies" obviously does not work if the daemon forks-and-exits for whatever reason. xinetd also does not work for you if a server wants to listen to multiple sockets, or (these days) should start when an udev request arrives for it … or maybe you want to manually start the thing because you know you'll need it in a few minutes …

… and shutting it down cleanly has its own grab bag of problems, which (x)inetd does not address AT ALL.

I mean, come on. You can find some piece of code which does a half-assed job of (almost) anything systemd can do . What nobody in this whole discussion has ever mentioned is a program which today improves on anything that systemd can do.

Which init system for Debian?

Posted Dec 8, 2013 16:24 UTC (Sun) by nix (subscriber, #2304) [Link]

Quite. Which is why, violently conflicted though I am on systemd and concerned though I am about its relentless scope creep and apparent desire to take the entire core of the system and wrap it up in a single package (eep -- only, well, glibc and the kernel do that already and nothing bad happened), I'll probably eventually end up using it on systems other than VMs. It does, after all, work, and work well: better than all the competition. It's just a scope-creepy monster at the same time.