Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 8, 2013 12:56 UTC (Sun) by anselm (subscriber, #2796)
In reply to: Another daemon for managing control groups by cas
Parent article: Another daemon for managing control groups

that's called modularity

That's called trying to defend an obsolete hodgepodge of barely cooperating pieces of software – which is limited in its potential, error-prone, and difficult to explain to newcomers.

»Modularity« might be an actual asset if the current system had been designed that way, which it hasn't. The current system has been pulled together from a variety of sources with little thought given to its interaction, maintainability, and teachability. It is easy to replace individual pieces of it only because the pieces don't really talk to one another, which means that a lot of useful functionality that would be both very convenient to have and reasonably straightforward to implement (as shown by systemd) simply does not get implemented at all.

Your »modularity« argument amounts to claiming that cars don't make sense because in your horse-and-buggy setup, which has several centuries of tradition behind it and allows you to travel the two miles from the farm to the village in a mere half hour, you can replace the engine and the passenger compartment independently of each other.

systemd is the death of innovation. it has its tentacles in way too many pies, and once you switch to it you're stuck with it - any replacement would have to do *everything* that systemd does

I presume this is why you use something like GNU Hurd rather than Linux. The Linux kernel, after all, has its tentacles in way too many pies, and once you switch to it you're stuck with it – any replacement would have to do everything that the Linux kernel does. Which is why no innovation ever takes place inside the Linux kernel.

Systemd is really quite modular once you look past the source tarball. Its PID 1 mostly does the things it does because it makes technical sense to put them into PID 1, not because it is supposed to do everything – lots of systemd's functionality resides in separate executables that can be dealt with individually, and their interfaces are, on the whole, documented way better than those of the traditional system. It is also quite possible to replace parts of systemd with your own code even now if you think you can do better than the systemd developers.

By contrast, with the traditional setup many distributions have been forced to come up with their own solutions for things that stock SysV init and friends simply do not do to begin with, especially when it comes to configuration and management, and that leads only to widespread incompatibility and the re-invention of the (square) wheel rather than (desirable) modularity.

to post comments

Another daemon for managing control groups

Posted Dec 8, 2013 20:32 UTC (Sun) by cas (guest, #52554) [Link] (13 responses)

> »Modularity« might be an actual asset if the current system had been
> designed that way, which it hasn't.

except that it was - it's a large part of the point of the "small tools" approach.

but don't let facts get in the way of your dumb argument.

> I presume this is why you use something like GNU Hurd rather than Linux

ah, yes. the single most cogent and popular argument of systemd pushers - "you like modularity therefore you must hate linux and love microkernels".

as someone else in this thread so eloquently put it, the only answer to that is "fuck off". and take your moronic straw-man with you.

> Systemd is really quite modular once you [...]

systemd is really quite modular once you redefine "modular" enough so that a monolithic monstrosity qualifies. combine that with the systemd-favourity argument that "modularity is stupid and who wants it anyway?" and you get insanity.

Another daemon for managing control groups

Posted Dec 8, 2013 20:54 UTC (Sun) by anselm (subscriber, #2796) [Link] (10 responses)

except that it was - it's a large part of the point of the "small tools" approach.

Yeah right. You know inetd comes from 4.3BSD and SysV init from – wait for it – AT&T's Unix System V? No wonder they don't talk to each other and are configured completely differently from each other. Great design.

systemd is really quite modular once you redefine "modular" enough so that a monolithic monstrosity qualifies. combine that with the systemd-favourity argument that "modularity is stupid and who wants it anyway?" and you get insanity.

Check out myth #1 at The Biggest Myths, where Lennart Poettering says

1. Myth: systemd is monolithic.
If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries are separated out so nicely that they are very useful outside of systemd, too.
A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

Who's putting up straw men now?

Another daemon for managing control groups

Posted Dec 10, 2013 12:34 UTC (Tue) by dgm (subscriber, #49227) [Link] (5 responses)

>> A package involving 69 individual binaries can hardly be called monolithic.

It can. Modularity is not a question of the number of pieces, but of the coupling between them.

AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.

Another daemon for managing control groups

Posted Dec 10, 2013 13:01 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

There is a page on the systemd site which lists the interfaces systemd adheres to between its components. It has been linked from this thread at least twice (search for "Promise").

Another daemon for managing control groups

Posted Dec 10, 2013 13:21 UTC (Tue) by mchapman (subscriber, #66589) [Link]

> AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.

I think the big problem here is that people are talking about (at least) two different kinds of "modularity".

There have been comments claiming that too much is being put into PID 1. The "69 individual binaries" comment should be a good counterclaim to that -- the majority of those binaries live in /usr/lib/systemd/ and are separate from PID 1 specifically because their functionality doesn't need to run in PID 1.

That's one kind of modularity. The other is "replaceability". Here I would have to agree with you: most of those /usr/lib/systemd/ binaries are not really that replaceable. (I'm not sure I'd say the interfaces are "undefined and continuously changing", though -- that makes no sense from a maintainability point of view, and at least the ones I poked directly on my system all responded nicely to --help). Perhaps this is a concern to some people... but I'm not sure what the alternative might be. They're only supposed to be used internally by systemd, so replacing them with functional equivalents wouldn't change anything.

Another daemon for managing control groups

Posted Dec 10, 2013 13:34 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.
You are, there are lots of interfaces that can be reimplemented independently, and most of the systemd interfaces are fully documented.
http://www.freedesktop.org/wiki/Software/systemd/Interfac...

Another daemon for managing control groups

Posted Dec 10, 2013 16:55 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

AFAIK, systemd modules are not "replaceable" in any sensible way, because they are highly coupled, their interfaces undefined and continuously changing. But I may be wrong.

You are partially wrong (interfaces are defined and described here). But more important is somewhat relevant question: why do you care?

It's true that systemd components are separated into a bunch of small programs designed to work together… just like UNIX was always developed. It's true that systemd components are not designed to be easily replaceable… just like UNIX components were never designed to be easily replaceable. It's kept as one single (and relatively large) source codebase… just like which was delivered as large code dumps on a few tapes.

Basically the story with systemd always goes in the same circle again and again. Somewhat like this:

Detractor: Systemd developers totally don't understand “Unix Way” because they are doing A, B and C!
Supporter: Well, systemd does X, Y and Z—why it's not enough.
Detractor: If systemd does not do A, B and C then it's against “Unix Way”, it's an abomination to be stopped at any cost. Only if you do A, B and C you can call yourself “true Unix believer”
Old beard: I was there at the beginning and I can vouch that Unix was never about A, B or C.
Detractor: You, the doited idiot, you've made Unix, but you totally don't understand it. Your Unix never did A, B and C but of course it does not matter: if you don't do A, B or C then you are doing things wrong!

When you define something which Unix never did, something which it never planned to do, something which only some other systems ever did as as “true Unix Way” then it's kind of hard to discuss your arguments rationally.

Unix components were never intended to be used on other platforms. Many components were ported to other platforms or rewritten in compatible way (GNU project is most famous for that), but it was not something UNIX creators ever cared about and it was not something they planned for.

Yes, components had more-or-less clean interfaces, but UNIX man was designed to always usee UNIX troff and it was never designed to use groff, UNIX cc was designed to be used with UNIX as and UNIX ld, it was not compatible with other tools (indeed even GNU toolchain sometimes is forced to use native components on some systems because they are tied to tightly to other components). So why, just why systemd should be designed differently? Because some people who don't plan to use systemd anyway desire that? Makes no sense to me.

Another daemon for managing control groups

Posted Dec 11, 2013 16:59 UTC (Wed) by dgm (subscriber, #49227) [Link]

> You are partially wrong (interfaces are defined and described here).

It happens to me all the time. Oh, well.

Another daemon for managing control groups

Posted Dec 11, 2013 22:15 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Yeah. systemd is not monolithic, except that if cooperation with someone else to use a common library is asked for, well, they can just sod off. Wonderful. (Mind you, given Lennart's ability to antagonize other people I can see why he might want to avoid cooperating with people in such areas. He'd never be able to keep it up.)

Another daemon for managing control groups

Posted Dec 12, 2013 14:02 UTC (Thu) by HelloWorld (guest, #56129) [Link] (2 responses)

> Yeah. systemd is not monolithic, except that if cooperation with someone else to use a common library is asked for, well, they can just sod off.
So systemd is "monolithic" because they refuse to use a library that a) doesn't exist as of yet and b) doesn't buy them anything?

Another daemon for managing control groups

Posted Dec 14, 2013 19:39 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

It's not that they refuse to use it. They refuse to even discuss design of such a library, and say that if one were to exist they would ignore it.

Another daemon for managing control groups

Posted Dec 14, 2013 21:18 UTC (Sat) by raven667 (guest, #5198) [Link]

What exactly would the abstraction layer be that such a library could provide, what code would be in it and what code would be needed to interface with it? This is pretty low level, if it can't effectively encapsulate complexity then there isn't any point. I'm not an expert but my guess is that for someone who is familiar with the systemd code base and the kernel interface they have an idea of what abstractions are possible and how useful they could be and decided that the cost/benefit isn't there to encapsulate this logic in a library.

How is this possible abstraction different than the dbus interface these tools are planning to provide?

Another daemon for managing control groups

Posted Dec 14, 2013 13:42 UTC (Sat) by kleptog (subscriber, #1183) [Link] (1 responses)

The thing is, there is no actual good reason why init, inetd, cron and at are separate processes with incompatable config files and features. They all start processes, just for slightly different triggers.

init doesn't let you specify a user to start as. cron can in /etc/crontab, but not in /etc/cron.d. cron and at capture output and send it via email, the others don't have a proviso for log output. cron allows configuration of environment variables, init doesn't.

None of them support ulimits, none of them support cgroups, There are no moves in that direction either.

And most importantly, none of them actually *manage* the processes they start. For example, you find the list of currently running cronjobs using ps, why? sysvint doesn't notice if a process dies or fails to start. For an actual production system you end up using something like daemontools, which despite having a lot less code than init actually ends up being more useful (especially the helper programs setuigid, envuidgid, setlock, envdir, softlimit which really should be standard stuff). ISTM people praising the Unix-way should be using daemontools as init, since it's modularity is much better than init's.

So in my opinion it's good that someone has picked up the ball and replaced all these mutually incompatible programs with a uniform system that allows me to configure everything about starting a process uniformly and manage them in a uniform way. Now if support for containers/umask/ulimits/chroots/etc is added it works for all kinds of processes, not just for the init/inetd/cron/at daemon that happens to have gotten support for it.

As for the journal, in daemontools you use multilog to replace syslog and logrotate in one go. All systemd has to do is something better than multilog (which isn't hard) and I think you have a winner.

So as far as I can see, systemd is a win for people who want to use their systems to do real work.

Another daemon for managing control groups

Posted Dec 14, 2013 21:02 UTC (Sat) by jubal (subscriber, #67202) [Link]

So as far as I can see, systemd is a win for people who want to use their systems to do real work.

That's a bold statement. (In both general and the Irish meaning.)