PEACEFUL systemd thread - GNU/Linux
venam
(15-06-2017, 04:02 PM)z3bra Wrote: I disagree with you there. It is only said so because orphaned programs get adopted by PID 1. Proper service handling can be done by any process, as long as their children don't double fork themselves (which they shouldn't do on their own anyway).

Yes, it doesn't have to but it's easier to do that from PID1.
In the case where it's not it could still fulfill the following:
  • Be detached from a terminal
  • Don't have any way to reacquire one (SID != PID, maybe the service manager (not PID1) will be able to reacquire one)
  • Be immune to signals that would interfere with it (example: sent to the group instead of to it directly)
  • Have the environmental values reset (no file descriptor, reset masks, cwd to /, etc..)
In the case of a daemon that is started by a service manager that is not PID 1 the SID and GID will be the one of that service manager.
Thus it's subject to signals sent to that group. And if the service manager dies (which would not happen with PID1) then all the services will become orphan.

Those are not too big of an issue, you're right, it doesn't have to be PID 1.

Here's a thread that discusses this a bit: https://unix.stackexchange.com/questions...472#197472
Another one that talks about orphaned process not necessarily being reparented to PID 1 and thus could be reparented to that service-manager https://unix.stackexchange.com/questions...361#177361

The discussion is going a bit off-rails, sorry for that.
z3bra
No problem, we're discussing about init systems, which systemd is.
The fact PID 1 cannot die is false. It is a process like any other which is subject to segfaults, oom and the likes. You statement that:

Quote:if the service manager dies (which would not happen with PID1) then all the services will become orphan.

is a bit irrelevant, because it COULD die. If it does, you'll have more problems than sshd not running though, but it could. If you service manager is badly written, and thus die, then moving all this logic to PID 1 won't fix the crashes. It will only weaken PID 1.

As for daemons being orphaned, it shouldn't happen if your daemon manager exits correctly (eg, cleanup by killing all children or whatever). If it does though, then yes, you will have orphaned processes. But it is IMO better than a kernel panic!

Regarding the environment, I agree that it should be reset by the service manager before firing up the service. As for the ID of the service manager, they are technically root:root by default (like PID 1), and each service is free to launch themselves as separate users to drop their privileges.

IMO, there is no valid technical reason to keep service management in PID 1. Not even for orphaned processes, as you will adopt them without any context (it could as well be a simple user process, you can treat all of them as daemons).

To get back to the topic, this is one of the first flaws systemd has regarding service management. The internal logic seems to be okay though, but it is not managed at the good level.
venam
(16-06-2017, 05:00 AM)z3bra Wrote: is a bit irrelevant, because it COULD die. If it does, you'll have more problems than sshd not running though, but it could. If you service manager is badly written, and thus die, then moving all this logic to PID 1 won't fix the crashes. It will only weaken PID 1.
Indeed I agree.

(16-06-2017, 05:00 AM)z3bra Wrote: IMO, there is no valid technical reason to keep service management in PID 1. Not even for orphaned processes, as you will adopt them without any context (it could as well be a simple user process, you can treat all of them as daemons).
After further reading (the links in my previous comment), I have to agree that there were a lot of solutions and aspects I hadn't thought of before.
Especially the fact that the parent of orphaned processes doesn't have to be PID1 and is implementation specific and that reaping zombies isn't a requirement of the init anymore. Init could be, as far as the service manager is concerned, only responsible to respawn it in case of failure.

(16-06-2017, 05:00 AM)z3bra Wrote: To get back to the topic, this is one of the first flaws systemd has regarding service management. The internal logic seems to be okay though, but it is not managed at the good level.
Then, according to you, it's a matter of separation of tasks and delegation through child-processes?
z3bra
Privilege/task separation is great indeed. If the service manager dies, your OS should keep working without a hitch. Neware not falling too deep in the delegation though, and spawning 3 processes per service like runit does for example
grah
I'm unable to give any technical input regarding systemd as I don't know much about init systems. Here are a few links that might be useful:

http://without-systemd.org/wiki/index.ph...st_systemd
https://suckless.org/sucks/systemd/

One thing I've noticed is how different distros handle systemd services. For example when installing mpd on Arch you will be required to enable the service manually whereas on Debian it will enable it automatically. I'm personally in favour of manually enabling/starting services but in Debian's defense at times it's very convenient. The problem with this for me is that it assumes you want the service running at startup, which is reasonable in most cases but not all. Another problem is that by default the program you just installed could've pulled in some other services such as avahi, and now they're also enabled. I guess that's not really a problem with systemd but how different distros incorporate it.

Systemd unit files are stored in sub-folders, which is a nice way to organize things but it could confuse some users. For a user having service scripts in either /etc/rc.d, /etc/init.d, or /etc/sv is much more straightforward.




Members  |  Stats  |  Night Mode