Which init system for Debian?

Posted Nov 15, 2013 15:47 UTC (Fri) by khim (subscriber, #9252)
In reply to: Which init system for Debian? by paulj
Parent article: Which init system for Debian?

I was responding to anselm, in the comments of this LWN article.

Where LWN means “Linux Weekly News”.

I disagree only with saying that it's impossible, and only possible with the monolithic Systemd way.

How can you disagree with truth? Yes, it's impossible and it's only possible with the “monolithic systemd way”.

The only topic I have an interest in is the question of whether the same Systemd features are possible with a modular system under a SysV init, with functionality distributed over, less tightly-bound components. I think they are, as in my experience such systems have existed before.

Really. Ok. Let's discuss them, then. Note that systemd is not some huge monolythink binary: there are actually many specialized processes, but they all are developed together and are compiled as a large package. Which obviously means that “distributed over, less tightly-bound components” should include packages developed by separate teams and then bound together by packagers. This automatically excludes things like MacOS's launchd and Solaris' SMF (because, you know, they are tightly bound to the specific version of kernel, specific version of SysV init fork, etc). So… what we are discussing here? What “systems [that] have existed before” have you in mind, hmm…?

Yes, if you forget about “distributed over, less tightly-bound components” then you'll find quite a few such systems—but they don't exist under Linux today. Your AIX/MacOS/Solaris/Unixware packages are only interesting as a source of inspiration, they are not ported to Linux and it's not clear if they ever be proted (usually they are tied to some details of the appropriate systems which don't exist on Linux thus you can only use them as an inspiration, the code must be written from scratch or heavily modified). You may as well discuss design decisions of BeOS or Windows: they are just not relevant to discussion in question.

You can not simultaneously claim nothing prevented service management super-daemons [from] being written when it's perfectly cleat that they were not written. They were not written in twenty years of Linux history and they were not written in two years which passed after systemd introduction—which means that something is most definitely cause this phenomenon. “Simple to do” things are by definition… well… are simple to do and don't take years and/or decades! It may be technical problems or it may be lack of manpower, whatever. The fact still remains: they are not available today. If you want proper socket activation with seamless restarts, keep-alive capabilities and so on then systemd is the only game in town on Linux. There are other solutions developed for other OSes but they are tightly bound to these OSes and thus are not suitable for Linux distribution.

Which init system for Debian?

Posted Nov 15, 2013 19:03 UTC (Fri) by nix (subscriber, #2304) [Link] (9 responses)

You are apparently claiming that inetd, xinetd, et al do not exist, and that their functionality can only be implemented by something like systemd, as a direct response to comments pointing out that they do exist and are counterexamples to just that claim. Are you even reading the comments you're responding to?

Which init system for Debian?

Posted Nov 15, 2013 19:49 UTC (Fri) by anselm (subscriber, #2796) [Link] (8 responses)

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

Which init system for Debian?

Posted Nov 20, 2013 4:10 UTC (Wed) by ThinkRob (guest, #64513) [Link] (2 responses)

launchd isn't as tightly bound as you think. It's been ported to other OSs, although I don't think it's used outside of Mac OS X.

Which init system for Debian?

Posted Nov 20, 2013 4:43 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

Has it been ported to non-BSD kernels?

Which init system for Debian?

Posted Nov 21, 2013 0:53 UTC (Thu) by ThinkRob (guest, #64513) [Link]

It was ported to FreeBSD at least twice AFAIK.

So that makes two different kernels (XNU and FreeBSD) that it's run under. (I know XNU uses FreeBSD code in its kernel, but it's still a pretty different beast.)