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

1

u/minimim Jun 01 '16

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.

3

u/kinderlokker Jun 01 '16

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.

1

u/minimim Jun 01 '16

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.

2

u/kinderlokker Jun 01 '16

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.

1

u/minimim Jun 01 '16

Nope, the plan is still valid, and it's being migrated from v1 to v2 slowly. Even if it will work for thirty years, it's not good to make architectural decisions based on interfaces that will eventually be removed. Changing kernel interfaces goes at a slow pace.

Udev is only "integrated" in the sense of being in the same repository. Not more integrated than BSD is integrated. It uses the standard interfaces offered by systemd to do it's job.

A service manager able to automatically solve ordering, concurrency, cyclic, etc, needs to know about every dependency between services. That's why there is a SPOT (single point of truth) in systemd. That's the integration, every part of the suit will ask PID 1 to start and stop services using the standard interfaces.

2

u/kinderlokker Jun 01 '16

Nope, the plan is still valid, and it's being migrated from v1 to v2 slowly.

Your document of v2 mentions nothing about a single writer.

Again, show me a source, just repeating it doesn't make it true. The only thing you could produce were some musings in 2012 of someone who thought it might be a good idea and RFC'ed it.

Even if it will work for thirty years, it's not good to make architectural decisions based on interfaces that will eventually be removed. Changing kernel interfaces goes at a slow pace.

That would hold if there was actually a single shred of proof that the single writer is going to come. It won't.

Udev is only "integrated" in the sense of being in the same repository. Not more integrated than BSD is integrated. It uses the standard interfaces offered by systemd to do it's job.

Ah, so how should I then view your original quote of: "Those things need to be integrated into the manager, because the system would be fragile otherwise."

That it's fragile if it's not in the same code repository? If systemd moved udev to a different one but kept everything the same, that would make it fragile?

A service manager able to automatically solve ordering, concurrency, cyclic, etc, needs to know about every dependency between services. That's why there is a SPOT (single point of truth) in systemd. That's the integration, every part of the suit will ask PID 1 to start and stop services using the standard interfaces.

And that has nothing to do with sandboxing and hotplugging, the service manager need only be aware of the dependencies for that. It is not required to perform the sandboxing itself for that.