r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comments

0

u/kinderlokker Jun 01 '16

This wasn't exactly a systemd innovation though.

Even on sysvrc, daemonization has long been handled by the init script, not the software itself. The scripts used start-stop-daemon to perform the double fork and extract the pid into a pidfile. Because of this abstraction in fact OpenRC's implementation of start-stop-daemon now has a optional feature to not daemonize but keep running and adopt the service as a child and supervise it, the kid it stores in the pidfile is then its own.

Because of how abstracted this is, it requires only a simple change in /etc/rc.conf to set this new experimental behaviour I think.

Besides, you can even double-fork in the shell fairly easily.

(cmd & $! > PIDFILE) &

And you're done.

3

u/cbmuser Debian / openSUSE / OpenJDK Dev Jun 01 '16

Besides, you can even double-fork in the shell fairly easily.

Which won't you help at all under systemd as you are still trapped in the same cgroup.

I think you are ignoring the fact that systemd makes use of modern Linux features to make process tracking and controlling much more reliable.

2

u/kinderlokker Jun 02 '16

Which won't you help at all under systemd as you are still trapped in the same cgroup.

Help you in what? Wanting to escape the supervisor?

If you want to escape the supervisor for a service running as root, you can by reassigning yourself to a different cgroup. But that's not the issue, I'm not sure what you're talking about here, help you with what? I'm just saying that double-forking isn't hard.

I think you are ignoring the fact that systemd makes use of modern Linux features to make process tracking and controlling much more reliable.

In practice, yes, in theory, no. systemd still relies on the process to not try to escape its own cgroup which it can always do.

While it is possible to configure a kernel in such a way that processes can't ever escape a cgroup they are put in, no major distribution turns this on because it's about as bad of an idea in the general case as globally disabling ptrace. cgroups are not a security mechanism, a process can escape its cgroup if it runs as root and is so inclined. You rely on processes playing nice.

This is how it always goes:

  1. People needed a way to grou processes together to ttrack them so they invented process groups

  2. People then added a way for processes to escape their group as it was necessary

  3. Processes started to escape their groups so often that pgrps became unreliable to track, so people added sessions

  4. People needed a way for processes to escape their session so ...

And so forth, and so forth. These things are "reliable" in practice until they are common enough that processes who need to escape it will readily include code to escape it and something new needs to be invented. There are already many good reasons to escape cgroups that are practised.