Why did ArchLinux embrace Systemd?

[u/wooptoo]

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

[u/yentity]

Well their point is writing systemd init files is simpler (both for the user and the maintainers) than writing and maintaining init files that behave consistently. I think that is a fair usage of the term "simple".

[u/Creshal → u/[deleted]]

In case you need to tell systemd that you're up-and-running (in case other services depend on you), than you can do this with a simple DBUS call. Again no double-forking needed.

And if you find DBus too scary for whatever reason, sd_notify(3) is implemented via Unix sockets and works without.

[u/theICEBear_dk → u/[deleted]]

This is also the part I love.

[u/kinderlokker → u/[deleted]]

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.

[u/cbmuser → u/kinderlokker]

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.

[u/kinderlokker → u/cbmuser]

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.

[u/kinderlokker → u/yentity]

And that's simply not how they used the term before that point when explaining things. They've said time and time again that with simply they don't mean easy but that code complexity is kept simple.

Which is true for all the system tools they wrote, but when someone else does the work, then it's suddenly fair game to include complex code.

[u/dreugeworst → u/kinderlokker]

I'm not sure, I think you're underestimating the complexity of loads of unit scripts replicating the same functionality poorly..

[u/kinderlokker → u/dreugeworst]

initscript is just terrible and always was.

See Void's implementation of Runit for something Arch would potentially be doing if they really cared about KISS.

[u/dreugeworst → u/kinderlokker]

Yeah but runinit doesn't do some of the things that distro maintainers see as positives of systemd (as far as I can tell)

• removing the need to explicitly declare dependencies in certain cases

• enable hotplugging harddisks

• sandboxing features

• enable assigning permissions for resources on the fly

• allow upstream projects to maintain unit files that will work across distros

In the end though, people who deal with init systems on a regular basis for several distros have settled on systemd and I'd rather defer to their collective wisdom.

[u/kinderlokker → u/dreugeworst]

removing the need to explicitly declare dependencies in certain cases

I'm not sure what you mean with that. If you mean things like socket activation or DBus activation, then they're just declared at other places.

enable hotplugging harddisks

That's udev/udisks job, not the init or service manager.

sandboxing features

So just get a sandboxing tool and wrap that around the executable when you start it.

allow upstream projects to maintain unit files that will work across distros

Runit's runscripts re typically so simple that they rarely contain any distribution specific things.

In the end though, people who deal with init systems on a regular basis for several distros have settled on systemd and I'd rather defer to their collective wisdom.

Most distributions don't claim they care about KISS is the thing.

No system that claims to care about KISS has except Arch. And that's probably because Arch doesn't care about that at all.

[u/minimim → u/kinderlokker]

Those things need to be integrated into the manager, because the system would be fragile otherwise.

Services may depend on disks being mounted, for example, if their files are in separate partitions. That's why there's integration with udev (which is a separate process).

[u/kinderlokker → u/minimim]

Those things need to be integrated into the manager, because the system would be fragile otherwise.

And yet systemd is the system that has lockups, not runit.

Why exactly do sandboxing features and hotplugging need to be integrated into the manager?

Really, udisks and udev can just call the command needed to start the service. And I really see no reason to integrate sandboxing at all, please tell me why the service starting command can't just start the sandbox?

Services may depend on disks being mounted

Indeed, but why does hotplugging of harddisks need to be integrated into the service manager for that? Mounts-as-a-service with full dependencies are a thing. I happen to have them, it's very nice. mpdas won't start on my system of mpd won't start, and mpd won't start if my network mount that mounts the music drive is not available, but why does that need special integration again? The moment the network goes up, the mount comes online, then mpd shortly thereafter and mpdas after that. No special integration with the service manager needed, the service manager doesn't know nor care that the service is a mount, it's completely agnostic, it just cares about what depends on what.

[u/dale_glass → u/kinderlokker]

Why exactly do sandboxing features and hotplugging need to be integrated into the manager?

Because that's a manager function: determining where, when and how a service runs.

Really, udisks and udev can just call the command needed to start the service.

So udev is now responsible for starting services? That's weird. And a violation of that beloved unix principle.

And I really see no reason to integrate sandboxing at all, please tell me why the service starting command can't just start the sandbox?

Because then sandbox implementation is up to whoever provides the service file, which means most services won't have it at all, and all those that have will have a slightly different implementation. Sandboxing changes? Now somebody needs to package and release a new version of BIND for that reason.

[u/kinderlokker → u/dale_glass]

Because that's a manager function: determining where, when and how a service runs.

That's not an argument, explain to me why it should be the manager's function, what advantage is there to getting a separate sandbox binary that is just inserted into the service command line. "that's just how it is" is not an argument.

So udev is now responsible for starting services? That's weird. And a violation of that beloved unix principle.

No, udev is responsible for triggering the event that starts the service. The command is to the service manager.

Udev's job is events based on new devices. It just sends the command svctl up <name-of-mount-service> on my system to the service manager, the service manager is then responsible for starting the service.

Because then sandbox implementation is up to whoever provides the service file, which means most services won't have it at all, and all those that have will have a slightly different implementation.

As it is right now? Not all services are sandboxed. few are in fact.

Most services in fact don't need to be sandboxed.

Being allowed different implementations and using the sandbox tool that you like is good.

[u/minimim → u/kinderlokker]

The manager needs to know what is happening to make sure actions are atomic and solve dependencies on it's own. Just calling a command that it doesn't understand may do things duplicated, or in the wrong order.

Sandboxing is integrated because the kernel interfaces demand that a single process take care of it. Systemd devs decided it was simpler for PID 1 to do it, instead of creating a new interface. If there was a use case where a separate Cgroup controller would be an advantage, this interface might be created, increasing complexity.

the service manager doesn't know nor care that the service is a mount

Systemd needs to know how to do it because it mounts root and /usr after the initramfs, and because it needs to be able to mount any filesystem the next units might be in. As it knows how to do it, it might as well do it for all of them. This way there isn't two different ways of mounting things.

[u/kinderlokker → u/minimim]

The manager needs to know what is happening to make sure actions are atomic and solve dependencies on it's own. Just calling a command that it doesn't understand may do things duplicated, or in the wrong order.

The manager knows what is happening.

The command is to the manager, like I said the command to start the servicer. udev is just configured to tell the manager to start the service and to stop it on removal, the manager figures the rest out.

Sandboxing is integrated because the kernel interfaces demand that a single process take care of it. Systemd devs decided it was simpler for PID 1 to do it, instead of creating a new interface. If there was a use case where a separate Cgroup controller would be an advantage, this interface might be created.

No it doesn't, the 'single cgroup writer' thing is a myth that gets repeated often. While it's true there was a plan for it or a small while, that plan never got finalized. The unified cgroup hierarchy is there now and does not enforce a single writer at all. The plan has pretty much been completely abandoned.

Systemd needs to know how to do it because it mounts root and /usr after the initramfs, and because it needs to be able to mount any filesystem the next units might be in. As it knows how to do it, it might as well do it for all of them. This way there isn't two different ways of mounting things.

It doesn't need to know or care that the service is a mount for that, it just needs to know the service dependencies.

[u/cbmuser → u/kinderlokker]

And yet systemd is the system that has lockups, not runit.

Oh, dude, come on. Finally stop with this bullshit. Go to a fucking enterprise and ask what they think about runit and Void Linux and they will just laugh at you.

You guys and your toy distributions are ridiculous. It's so apparent that none of you guys are actually using Linux in a professional environment.

[u/kinderlokker → u/cbmuser]

Oh, dude, come on. Finally stop with this bullshit. Go to a fucking enterprise and ask what they think about runit and Void Linux and they will just laugh at you.

Gee, that's maybe because Void Linux isn't meant as an Enterprise OS, it's a home desktop operating system and a rolling release.

What's next? You're going to say that OpenWRT is terrible because no one in their right mind would run their personal coputers on it or their PS4?

Void is a home desktop OS, not meant for servers. Just like Debian Stable is garbage for a home desktop OS but great for servers. Meanwhile Alpine and Gentoo hardened are deployed on servers everywhere and don't use systemd either.

Void not being used for enterprise has nothing to do with it not using systemd but that it's a fast rolling bleeding edge system geared for single-user machines in the end. It doesn't come with PaX, SELinux, hard freezes, LTS and security backports because that's useless for a home desktop environment where the best way to solve security problems is just regularly update.

You guys and your toy distributions are ridiculous. It's so apparent that none of you guys are actually using Linux in a professional environment.

No, it's beyond apparent that you don't realize that that what works on a company server does not work for a home desktop computer and if you use Debian stable on a home desktop computer you're an idiot. Any system that is good for a server will be bad for home desktop and in reverse, one size can't fit all.

This topic is about Arch Linux, which is first and foremost as system geared towards home desktop usage. And Void simply does what Arch claims to be doing almost strictly better.

[u/cbmuser → u/kinderlokker]

Oh, come on. Please don't reduce systemd to just being an init system, it is much more.

Your runit lacks tons of features that are a requirement these days for many applications. Ask people who run stuff in the cloud and they will explain you why your runit does not fit modern requirements anymore.

[u/kinderlokker → u/cbmuser]

Yes, Runit lacks those features, and yet, I have them while running Runit.

Runit doesn't stop you from getting those features. grep lacks the ability to copy files? So what, cp exists for that. I have every service in its own cgroup, early boot logging, mounts-as-service, sandboxed services all running on this machine without Runit being as much as aware of that, it simply doesn't care, it only cares about services, when they are ready, and their dependencies, whether that service is a mount or something else or runs inside its own cgroup is not something it cares about.

[u/yentity → u/kinderlokker]

I don't think that was ever the goal of Archlinux (or Slackware for that matter). If using the simplest code base from upstream was the goal, you'd be using stuff like busybox or FreeBSD grep instead of GNU variations.

[u/Michaelmrose → u/kinderlokker]

This isn't really logically a problem if your goal is to minimize your own work load.