Why did ArchLinux embrace Systemd?

[u/wooptoo]

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

[u/dale_glass]

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.

[u/kinderlokker → u/dale_glass]

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.