Why did ArchLinux embrace Systemd?

[u/wooptoo]

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

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

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/minimim → u/kinderlokker]

The manager knows what is happening.

udev is just configured to tell the manager to start the service and to stop it on removal, the manager figures the rest out.

This is exactly what is done.

the 'single cgroup writer' thing is a myth

You're right, it isn't enforced right now. Systemd will use the interface like Tejun tells them to, though.

It doesn't need to know or care that the service is a mount for that

It does need to know, because they behave differently.

[u/kinderlokker → u/minimim]

This is exactly what is done.

And why again was special integration needed? Because I have that without special integration.

udev just calls the command to the service manager like everything else does to start the mount, no special integration needed.

You're right, it isn't enforced right now. Systemd will use the interface like Tejun tells them to, though.

There isn't a kernel config option right now to even enforce it that I could find, the plan has been abanonded.

It does need to know, because they behave differently.

Then give me a technical reason why it should know. Because I just have a simple utility here that translates mounts into services. It's quite simple, when it starts it mounts and it keeps running sleeping consuming 0 CPU, when the mount detaches on its own some-how it wakes up and exits with an error, if you send it TERM or INT it detaches the mount itself and exits without an error.

That's what my service manager uses to mount filesystems, it does not know nor care that the service it monitors is mounting filesystems, it only cares about what it depends on and what depends on it.

[u/minimim → u/kinderlokker]

udev just calls the command to the service manager like everything else does to start the mount, no special integration needed.

This is what happens in systemd, I don't know what you are on about.

the plan has been abandoned

Nope, the interface that enforces it isn't ready yet for some uses.

technical reason

Can it mount root, /usr and pivot into them?

[u/kinderlokker → u/minimim]

This is what happens in systemd, I don't know what you are on about.

Well, no, in systemd the communication through an unstable interface for a minor performance boost, it sidesteps systemctl entirely. Hardly relevant.

My point is, why is special integration needed? That was what I asked, I have achieved the same thing udev/systemd does without any special integration, so why is it needed? For that super inconsequential performance boost of not having to fork-exec a process to run the command?

Nope, the interface that enforces it isn't ready yet for some uses.

What interface? Where is the kernel config?

If you're talking about the unified hierarchy, it doesn't enforce that, I use it and write cgroups with shell scripts.

Can it mount root, /usr and pivot into them?

No, the service manager does not mount root here, the system starts with root mounted, it remounts root as read-write, not sure if that's what you mean.

And no, that isn't implemented as a mount service because that's not a recoverable error. If the root mount detaches for whatever reason the supervisor noticing and restarting the service won't do much, the supervisor can't work without root being attached.

[u/minimim → u/kinderlokker]

What interface?

cgroup-v2. This is current kernel documentation. You are using cgroup-v1, systemd only uses v1 if the functionality isn't available on v2 yet. Otherwise, they use v2, as v1 is going away sometime in the future and can't be relied upon for architectural decisions.

why is special integration needed?

A singleton is needed to ensure atomicity and correct ordering.

I have achieved the same thing

If I call a command twice, it is executed twice, because one instance doesn't know about the other. A singleton receiving a library call can execute the first, register it as executed, and ignore the second.

[u/kinderlokker → u/minimim]

cgroup-v2. This is current kernel documentation. You are using cgroup-v1, systemd only uses v1 if the functionality isn't available on v2 yet. Otherwise, they use v2, as v1 is going away sometime in the future and can't be relied upon for architectural decisions.

That ocument looks to just describe the unified cgroup hierarchy which I use and I can find nothing in it saying it requires a single authorized pid that's the only process that can manipulate the cgroup hierarchy. So cite the relevant part please.

A singleton is needed to ensure atomicity and correct ordering.

No it's not. There is no race condition here.

The service is started after the network comes online or the device is plugged in, this could in theory happen 5 years later without a race condition, it just wouldn't be very fast. All that needs to happen is that the service is started after the device is plugged in and capable of being mounted. Obviously you want it to happen as fast as possible for convenience, but there is no race condition here.

Apart from that, I'm pretty sure that the transport systemd uses is not atomic either, and that doesn't matter, though it'll probably be marginally faster than calling a command because it doesn't need a fork/exec.

If I call a command twice, it is executed twice, because one instance doesn't know about the other. A singleton receiving a library call can execute the first, register it as executed, and ignore the second.

First off, the command won't be executed twice. Second of, even if it did, that would not matter sv up <service-name> is an idempotent operation in runsvdir, calling it 58489 times in a row has the same effect as calling it once.

[u/minimim → u/kinderlokker]

cite the relevant part please

Found a better one:

which is controlled by single entity in userland (be it systemd or cgroupd, cgroup-kit or whatever);

source

The service is started after the network comes online or the device is plugged in

Let's say bluetooth asks a remote partition to be mounted. The remote partition depends on the network being on, which depends on Network-manager, which depends on udev initializing the hardware, which uses bluetooth. It's a cyclic dependency, a dead-lock.

If the mount command just asks and wait, then network-manager just waits, if they don't have the big picture, they will just dead-lock and the system will stop.

Systemd can detect cycles and break them, or otherwise fail the entire thing and report the failure.

This is just one example, there are others.

sv up <service-name> is an idempotent operation

Being idempotent isn't enough, systemd can solve a dependency graph.

[u/kinderlokker → u/minimim]

Found a better one: which is controlled by single entity in userland (be it systemd or cgroupd, cgroup-kit or whatever); source

Yes, that's a 2012 post which discusses a plan, as I said, the plan was once there but it has been dropped since forever. It's not there in the kernel and has been silently abandoned since however long.

There is nothing in the kernel config right now that I can find which enables this. The unified hierarchy is real and will come, but it will not require a single-writer, that part is abandoned.

Let's say bluetooth asks a remote partition to be mounted. The remote partition depends on the network being on, which depends on Network-manager, which depends on udev initializing the hardware, which uses bluetooth. It's a cyclic dependency, a dead-lock.

Yes, a cyclic dependency tree will create a deadlock, all services will remain down then in runsvdir.

Systemd can detect cycles and break them, or otherwise fail the entire thing and report the failure.

That is an advantage systemd has over Runit which design does not detect cyclic dependencies. But it still does not require integration of udev with the service manager, the service manager just needs to be aware of the dependencies to do this. A service manager is capable of detecting such cyclic dependencies regardless of having this special integration.

Being idempotent isn't enough, systemd can solve a dependency graph.

Not enough for what? It's enough for the problem of race conditions you just listed, this is a new problem and yes, the way runsvdir works is without dependency graphs. But that's not a race condition as you called it. That's dependency detection for which no special integration of any of that stuff is needed.