
Rethinking PID 1 (2010) - ingve
http://0pointer.de/blog/projects/systemd.html
======
JoshTriplett
I remember reading this when it was first posted. The most interesting
section, by far, is "Parallelizing Socket Services". That makes it clear that
socket activation isn't really about delaying daemon startup or acting like
inetd (though inetd did provide some inspiration), but rather about being able
to launch services and their dependencies in parallel by making sockets
available before full daemon startup. Without that, any service depending on a
socket would need to wait for the complete startup of the service providing
that socket.

~~~
the_why_of_y
That's one advantage, but socket activation is such a good idea that it's hard
to decide what it is "really about": the other main advantages are that your
daemons no longer need to contain custom code to open the socket themselves,
and as a consequence don't need to start as root if they bind a low port so
you can get rid of the privilege-dropping code too, and also if your daemon
crashes the socket is still there buffering connection attempts until the
daemon restarts. It's really exploiting the fundamental tools that UNIX gives
you to the fullest to make things more secure and more robust as well as
faster.

------
fpoling
It is interesting that after 6 years from the article publication its key
concept of persistent sockets and services starting on demand is not there
yet.

For example, on the latest Fedora sshd/nginx/php-fpm still bind their
listening sockets themselves rather than receiving it from a process manager.
Similarly, if one wants to implement a socket activation in Go, it is not a
one-liner that just works, but it requires a third-party library to read the
socket passed over stdin.

As a result if for performance/security reasons one needs to customize few
service socket parameters, then at best one need to look at application-
specific configuration language for socket customization and hope that the
developers have not forgotten to expose the socket option that is needed. At
worst one uses LD_PRELOAD and similar atrocities to customize the sockets.

~~~
pquerna
sshd and apache2 for example both support systemd socket activation -- whether
distributions actually do that is up to the distros. CoreOS for example runs
sshd via socket activation.

~~~
fpoling
On CoreOS the integration is buggy. One cannot start a long running process
from sshd as when one logs out, all processes started from sshd are killed.

One can workaround that using systemd-run utility to start long-running
operation, but that is a privileged operation. Besides, it violates one of the
premises of socket activation that it should be completely transparent.

------
cvwright
Now I know there's tons of drama around systemd, and I'm really not trying to
re-start any of those flamewars. (please!)

But I never followed the topic that closely, so I'm honestly curious. Looking
back on this, he makes a pretty compelling case for his ideas. Were the
objections to systemd mainly disagreements with the concepts (parallelizing
socket services, etc)? Or was it more the way the ideas were implemented in
systemd that traditional sysadmins didn't like? (binary "registry-like" config
files, etc)

I only ask because, if most objections were about the implementation, then it
should be possible to create a system that achieves the benefits he's
extolling here, while keeping a lot of the "Unixy feel" that his detractors
prefer. If it's a more fundamental disagreement, then it's harder to see a
path that could make both sides happy.

~~~
ori_b
The objections I tend to hear aren't so much about the parts of systemd listed
in here, but about the way it seems to have grown to take over the rest of the
system.

For example, it has its own syslog replacement, login manager, dbus
implementation, network connection manager, dhcp server, udev implementation,
boot manager, etc. There's talk of making it a dependency of Gnome, which
would make Gnome and its components impossible to run on systems without
systemd.

~~~
sseagull
> which would make Gnome and its components impossible to run on systems
> without systemd.

This is my main complaint. Most programmers know that coupling separate
components is a bad idea[0]. After a while, the two components merge; they
will begin to interface to lower and lower levels of each other, with the
result being a giant mass of interdependent spaghetti code.

Your choice of desktop manager should not, in any way, dictate which init
system you use. And with system taking udev and everything else with it, it
may be almost impossible to separate out systemd ever again.

[0] I was going to link to the Stevens paper, but even wikipedia has an
article about the problems of coupling:
[https://en.wikipedia.org/wiki/Coupling_(computer_programming...](https://en.wikipedia.org/wiki/Coupling_\(computer_programming\))

~~~
digi_owl
Nifty.

Seems to me that while unix (and thus Linux) have traditionally leaned towards
data or stamp coupling, while systemd is over at common coupling.

------
saghm
What (if anything) are people's thoughts on runit? I started trying out Void
Linux a couple of days ago, which uses it by default. I haven't spent a whole
lot of time reading up on it, but from my initial understanding of it, it
seems to avoid the issues that people seem to have with both systemd and
sysinitv. (Of course, it might just be that it's not used by enough people for
anyone to have strong negative opinions about it)

~~~
anonbanker
runit is a fine init application. it might actually be better than OpenRC
(which most of, our[0] systems run). Void is a fantastic distribution made
better by a sane choice in init systems, and if you visit for that reason,
you'll stay for all the other good, sane, choices and community.

0\. [http://medicalcannab.is](http://medicalcannab.is)

------
gkya
There is a lot of comments in the Devuan thread [1] and they will be here too,
but we mostly skip over the actual problem systemd creates: very important
parts of the Linux ecosystem becoming tightly coupled as to form a huge blob
of programs where one either uses all or none. For one, I use Unix [2] as a
productivity tool, not as a server, so I interact with init stuff very rarely.
Thus I want a system that's easy to configure and debug. Systemd is the exact
opposite of that, so I don't want to use it. But if I don't want to use it,
now I have to find an alternative to or modify all the stuff that depends on
it. If it was only an init script that I had to replace, that's okay, but
there are tighter coupling between unrelated components and systemd. I've read
that Gnome people consider having it as a dependency. Udev is so tightly
coupled that Gentoo had to make a fork. But it should be enough to write a new
startup script for switching to another init system, not fork the entire
program I want to use. This is the problem with systemd.

[1]
[https://news.ycombinator.com/item?id=11601288](https://news.ycombinator.com/item?id=11601288)

[2] Arch Linux for long, nowadays FreeBSD

~~~
chris_wot
And yet, it's not actually that hard to configure or debug. How is fiddling
with symlinks and scripts easier than changing unit files?

~~~
gkya
Let me decide it.

If I don't want to use it, I should be able to swap it out. I shouldn't have
to patch Gnome, udev, and whatnot to not use systemd.

I don't have problems with systemd, what I feat is essential parts of GNU and
Linux infrastructure becoming directly dependent on it, at the actual software
level.

~~~
chris_wot
Have you considered using Knoppix? Or now Devuan? Because you don't have to
use systemd...

~~~
gkya
Heck. I have to mount my USB sticks. I have to run some Gnome apps. What part
of that you don't understand? I don't want to have to load my drivers manually
just because I don't want to use systemd. Udev is the thing that probes
devices at boot time, isn't it? I don't want to fork Emacs, on which my life
depends, because dbus becomes a hard dependency, which becomes coupled to
systemd. Are you paid to not understand?

At the end of the day, I've left GNU/Linux behind anyways, I'm not talking for
myself but for the community.

~~~
wila
Avoiding the systemd thing here too, bsd for the win. Plenty has been said
about it and some will never understand what is wrong with it.

------
xenadu02
Just curious: why does the rest of the world ignore things like launchd,
libdispatch, etc?

~~~
adiabatty
Licensing, I'd guess. Also, Apple has no philosophical opposition to
integrating things; UNIX people do.

~~~
wila
Unix people? Not exactly the words i would have chosen, but i suppose you mean
that linux has gpl licensing. BSD type licenses work well with unix,but are
not compatible with the GPL.

~~~
cyphar
That's simply untrue. First of all, you can run any program on top of Linux
without licensing issues. Sure, Linux is GPL and so it much of the user land
(all of GNU being a prime example). But if your program doesn't use any of
those things outside of the "common use" of those components, the license is
irrelevant. However, BSD-style licenses (excluding the now-unused 4 clause
BSD) allow for sublicensing, so you can also include that code inside GPL
projects (sublicensed under the GPL).

------
stuaxo
Having a standard that works across distros is a good thing, at least things
don't feel as alien switching between redhat and debian (e.g. work and home).

------
apeace
Perhaps the title should have [2010] at the end.

------
tebruno99
Yeah, not much "rethinking" going on here anyway. Thought this was going to be
something actually valuable not "doing exactly what PID 1 is already suppose
to do"

------
d33
Based on last time when someone decided to rethink PID1 and wrote systemd, I'm
kind of afraid of any research in this field...

EDIT: flicked through the article and yup, it's 2010 and systemd is announced:
"You probably guessed it: what I suggested above as requirements and features
for an ideal init system is actually available now, in a (still experimental)
init system called systemd, and which I hereby want to announce."

2016 and I'd still say it's mostly experimental, but unfortunately reached
production machines now.

~~~
jle17
Well I would say it's functionnal and hasn't reached enough production
machines.

I don't understand the hate that systemd seems to bring in people. It may not
be perfect but the good largely outweights the bad and anyway most of the
arguments against it are the same copy pasted critics from day one, when they
aren't pure name calling against its author.

From a user perspective I for one am glad to be able to start and kill
services in a reliable maner, to have structured logging and a set of base
system components that are simple to use, coherent and well documented and
make taking advantage of otherwise painful to use Linux features easy.

Most anti-systemd people seem to be adverse to change and would rather stay on
SysV init, but seriously how much longer are we expected to stick with that
symlink mess of ugly scripts that can't reliably start a service in a
reproducible environment or track which process belongs to which service ?

I often see anti-systemd people advocate a move to FreeBSD, but there is a
reason behind the existence of the nosh or launchd projects... BSD init might
be cleaner than SysV but it suffers from some of the same problems.

~~~
thwarted
_and anyway most of the arguments against it are the same copy pasted critics
from day one_

The age of an argument doesn't negate the argument, especially if it has not
been effectively addressed since it was first proposed.

Those arguments are copy and pasted because they are still solid arguments and
they have been pretty much ignored or handwaved away.

That you're tired of hearing them doesn't mean that they shouldn't be
addressed. Those making the arguments are getting tired of having to repeat
them—just like the tech industry is tired of having to continuously debate the
government on cryptography: the arguments for liberty still stand, despite
being codifed two centuries ago.

~~~
Pyxl101
This seems like a pretty strong and specific technical argument in favor of
systemd: [https://lists.debian.org/debian-
ctte/2013/12/msg00234.html](https://lists.debian.org/debian-
ctte/2013/12/msg00234.html)

What's the best single page summary along with adequate details of the
arguments against systemd, and what's the professed alternative? From Googling
around, I haven't found anything with a comparable level of technical quality,
depth, and concreteness.

~~~
nickpsecurity
Interesting link btw. I think the number of features is oversold a bit. Others
here pointed out that, being so critical, it's best to have first process be
simple as possible with another doing the complicated stuff. So, those
features could be delegated into an isolated process via message passing.

However, it stood out that the shell scripts are complex and buggy in edge
cases. Quite opposite of robust programming we normally want. The socket
activation trick is nice. I could see following Systemd's lead to improve in
those two areas with a regular, minimalist init. Other features in other
processes. See where that goes before letting one component go octopus on
everything else.

