Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 8, 2013 20:32 UTC (Sun) by cas (guest, #52554)
In reply to: Another daemon for managing control groups by anselm
Parent article: Another daemon for managing control groups

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

to post comments

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