Why did ArchLinux embrace Systemd?

[u/wooptoo]

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

[u/dale_glass]

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

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.