That's my entire problem with systemd though: despite the averred modularity, it combines far too many concerns for anyone to understand how or why it works the way it does.
The other difference is PID 1 can't exit because Linux panics if it does. That's actually an argument for moving functionality out of PID 1.
There are other service managers out there which work outside PID 1. Systemd itself literally spawns non-PID 1 instances of itself to handle the user services. I suppose only the maintainers can tell us why they did it that way.
Maybe they are relying on the fact PID 1 traditionally reaps zombies even though Linux has a prctl for that:
https://www.man7.org/linux/man-pages/man2/prctl.2.html
PR_SET_CHILD_SUBREAPER
What if the issue is just that nobody's bothered to write the code to move the zombie process reaping to a separate process yet? Would they accept patches in that case?Ludicrously, that manual page straight up says systemd uses this system call to set itself up as the reaper of zombie processes:
> Some init(1) frameworks (e.g., systemd(1)) employ a subreaper process
If that's true then I really have no idea what the hell it is about PID 1 that they're relying on.
Edit: just checked the source code and it's actually true.
https://github.com/systemd/systemd/blob/main/src/core/main.c...
https://github.com/systemd/systemd/blob/main/src/basic/proce...
https://github.com/systemd/systemd/blob/main/src/basic/proce...
So they're not relying on the special signals handling and they even have special support for non-PID 1 child subreapers. Makes no sense to me. Why can't they just drop those PID == 1 checks and make a simpler PID 1 program that just spawns the real systemd service manager?
Edit: they already have a simple PID 1 in the code base!
https://github.com/systemd/systemd/blob/main/src/nspawn/nspa...
It's only being used inside namespaces though! Why? No idea.
I actually kinda think that can be an advantage for a service manager. If your service manager crashes an automatic reboot is nice, in a way. I doubt that's why they did it though.
I don't think it's gonna do that! I saw it in the source code: when it's running as PID 1, systemd installs a crash handler that freezes itself in a desperate attempt to avoid the kernel panic! It's pretty amazing. They could have written it so that PID 1 watches over the service manager and just restarts it if it ever crashes. I mean, systemd already supports soft-rebooting the entire user space which is pretty much exactly what would happen if PID 1 restarted a separate service manager.
Know what else I found in the source code? Various references to /proc/1. I'm starting to think that's the true reason why they want to be PID 1...