[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it



El Mon, 24 de Mar 2014 a las 9:42 AM, Kevin Toppins <Kevin.Toppins@gmail.com> escribió:
To all debian developers:


-> systemd is *fundamentally incompatible* with linux


Now, I realize that's a bold claim, but if you are up for some reading, I will prove it.

I'll bite.

I even went to Lennart Poettering's google+ page and ....

 -> tried to warn everyone there that systemd was headed for failure

 -> asked *Poettering* (in a different way) if he *could answer* what role systemd was to serve in linux


I said -> I have a question for you. If you can answer it with one, and ONLY one, concept that describes fully what systemd is I will consider I might have misjudged this.

He replied...

 -> systemd is a suite of basic building blocks to build an OS from

Maybe he was talking about the systemd project as a whole. systemd's source tree includes a number of different pieces of software, from udev to networkd. They are the basic building blocks. I will talk about systemd, the init system, specifically. This includes the journal (because it is mandatory and cannot be used without systemd) and the systemd binary, but not logind, udev, or anything else.

systemd starts, supervises, controls, and stops software according to dependencies, state, events, and chronology.

* start: simple execution, with optional environment and pre-created sockets. Decides to start when certain events occur (including device, socket, and bus events) or it is wanted by a starting unit, its own wants and dependencies are satisfied, its own conditions are true, and the "moment is right" (chronology is correct).
* supervise: monitors the process and optionally restarts it on failure.
* control: allows resource limits with cgroups, oom, nice, rlimit, and probably more. Hooks up its stdin/out/err.
* stop: stops the process and, optionally, that process's children (uses cgroups for this).

See the documentation for the following if they are not familiar to you:
* dependencies: Wants/WantedBy, Requires/RequiredBy (in man::systemd.unit)
* states: ConditionFileExists, ConditionFileExecutable, Condition* (probably in man::systemd.service)
* events: man::systemd.device, man::systemd.socket, Alias=dbus-org.foo.bar.service (in man::systemd.install)
* chronology: Before, After (probably in man::systemd.service)

I have heard you question why systemd recommends daemons to not fork/double fork. This is a pretty simple answer: it is costly and unnecessary, and systemd has less. To fork or daemonize is needless computation power that systemd does not require to be notified of the process's readiness. Furthermore, this makes it harder to supervise (track the PID and collect the stdout/err) the process. Lastly, it is a fair bit of unnecessary code on the daemon's part.

Any other questions?
--
Cameron Norman

Reply to: