Which init system for Debian?

Posted Nov 15, 2013 19:49 UTC (Fri) by anselm (subscriber, #2796)
In reply to: Which init system for Debian? by nix
Parent article: Which init system for Debian?

inetd and xinetd do exist and they do indeed support a restricted type of socket activation. However, comparing what inetd and xinetd can do to what systemd does is like comparing a bicycle to a fighter jet. They do somewhat strain the notion of »counterexample«.

The other thing is that systemd does what it does with a unified UI that uses the same configuration file structure and command line syntax across all the types of service it supports. From a pragmatic point of view this is a big advantage compared to cobbled-together approaches like »SysV init with inetd/xinetd and loads of custom shell scripts all over«, because apart from its technical advances it makes the system easier to understand, teach, and learn.

On the other hand, the idea of putting layers upon layers of badly-designed stuff on top of SysV init in the name of »loosely coupled modularity« makes for a system that is missing exactly the sort of tight integration that systemd offers, while providing only a subset of the features. People who are new to Linux – and I'm speaking as somebody who teaches Linux system administration for a living – need to get used to various obtuse file formats and directory arrangements like /etc/inittab vs. /etc/inetd.conf (or for that matter /etc/xinetd.conf) vs. /etc/init.d vs. /etc/rc2.d and so on, with distribution-specific tools to do this and that and no attempt at anything like consistency within the system itself, let alone between the implementations that various distributions provide. And that is the great ideal that can do whatever we require and that we need to defend at all costs from newfangled abominations like systemd and Upstart? Please.

Which init system for Debian?

Posted Nov 15, 2013 23:51 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

Oh, I know all that. But the fact remains that superdaemons *do* exist, and khim's apparent claim that they don't and are impossible without systemd is simply and factually wrong. That it's also in direct response to a comment that points out the actual existence of just such superdaemons makes me wonder if I've misunderstood what khim was saying somehow -- but if I have, it seems so has everyone else who's responded.

Which init system for Debian?

Posted Nov 16, 2013 0:04 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

But the fact remains that superdaemons *do* exist, and khim's apparent claim that they don't and are impossible without systemd is simply and factually wrong.

Citation needed. Badly. You claim that inetd and xinetd can seamlessly restart a service. Ok. I want to configure service in a mode where it's started when first client is calling it and is transparently restarted after crash (without dropping connections, of course). Nothing fancy, just basic requests which were implementable in Windows NT 3.1 twenty years ago. How to do that with xinetd?

Which init system for Debian?

Posted Nov 16, 2013 0:45 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

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.

Which init system for Debian?

Posted Nov 16, 2013 9:42 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

There was no shell hairball of init scripts needed with the super-daemon approach. The super-daemon could be launched and *managed* directly by init (inittab), and the super-daemon monitored things (sockets, ttys, etc) and launched services on demand (which could well go on to handle multiple requests, see, e.g., the wait option in inetd/xinetd).

The shell SysV init scripts were indeed a hairball and problematic and racy wrt start. I'm not saying anything to the contrary on that.

All I'm saying is that daemons to monitor resources, launch service handling child processes on demand, and manage their lifetimes (respawning, etc), have a long tradition already in Unix. I'm still curious what it is that can be done in PID 1 wrt child management that is impossible in the more distributed fashion? (And be careful not to conflate what was added to the process management capabilities by cgroups, and used to good effect by systemd, with functionality that is uniquely implementable in PID 1).

(Ob monolithic - Systemd apparently is modular only at compile time, not quite the modular/monolithic distinction I had in mind in my earlier comment).

Which init system for Debian?

Posted Nov 16, 2013 14:27 UTC (Sat) by raven667 (subscriber, #5198) [Link]

> (Ob monolithic - Systemd apparently is modular only at compile time, not quite the modular/monolithic distinction I had in mind in my earlier comment).

Well everything related to starting and stopping processes using all of the features the Linux kernel provides is in PID 1 but there are other ancillary daemons like udevd, journald, logind and utilities that do various jobs during system startup in /usr/lib/systemd, essentially C programs which replace the system setup logic that all the shell scripts used to do (setting the hostname, mounting filesystems with optional fsck, etc.)