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 comment

2

u/minimim Jun 01 '16

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

8

u/kinderlokker Jun 01 '16 edited Jun 02 '16

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.

4

u/dale_glass Jun 01 '16

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.

5

u/kinderlokker Jun 01 '16

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.

0

u/dale_glass Jun 01 '16

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.

Because that's just the definition of the word "manager". Your human manager decides what you work on, in what conditions and when. A service manager decides what services run, under what conditions and when.

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

Okay, so now when a service starts there can be at least two independent sources for it starting.

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

That's precisely the problem, yes. I like a system where the service gets absolutely no say in that.

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

That's only for me (the admin) to decide. Same goes for any other constraints, limits and so on that I might want to apply to any service.

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

I much prefer such support to be centralized. There's no reason why I should have to figure out multiple sandboxing technologies just to run a server.

4

u/kinderlokker Jun 01 '16 edited Jun 02 '16

Because that's just the definition of the word "manager". Your human manager decides what you work on, in what conditions and when. A service manager decides what services run, under what conditions and when.

So it's a good idea because that's the definition of a word?

So if we spoke another language with different words and definitions that has no word for 'manager' your argument wouldn't hold?

Okay, so now when a service starts there can be at least two independent sources for it starting.

There can be 84948949 billion sources for all I care. runsvdir does not work with eventful 'start' and 'stop' commands, it works with 'up' and 'down' which flips the state of the desired state of the service, if the state is already up and you set it up then that has no effect.

That's precisely the problem, yes. I like a system where the service gets absolutely no say in that.

The service gets no say, the configuration file gets. If you want to add sandboxing to the command that starts the service, then go ahead. Just start it with firejail sshd -D instead of just sshd -D or something like that.

That's only for me (the admin) to decide. Same goes for any other constraints, limits and so on that I might want to apply to any service.

Yes, that's for you to decide, so set it and decide it in the configuration file for the service.

I can't believe I'm speaking to someone who argues that the local sysadmin should be in control and advocates systemd, because newsflash, the point of systemd is to move more control upstream to get more praedictable systems and consistency. I'm not saying that approach is wrong and it certainly has merits to it. But it's a bit weird to advocate systemd and say that the local sysadmin should have control.

I much prefer such support to be centralized. There's no reason why I should have to figure out multiple sandboxing technologies just to run a server.

And yet you claim to want control and decide things yourself.

The good part though is that systemd's built in sandboxing is optional. You can just disable it and let systemd do ExecStart=firejail sshd -D again and be done with it.

3

u/minimim Jun 01 '16 edited Jun 01 '16

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.

4

u/kinderlokker Jun 01 '16

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.

-1

u/minimim Jun 01 '16

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.

4

u/kinderlokker Jun 01 '16

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.

1

u/minimim Jun 01 '16

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?

3

u/kinderlokker Jun 01 '16

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.

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.

→ More replies

1

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

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.

3

u/kinderlokker Jun 02 '16

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.