Turns out you're right and my knowledge was outdated. I seriously believed the systemd service manager was separate from its PID 1 but at some point they even changed the manuals to say that's not supported.

I was also corrected further down in the thread, with citations from the maintainers even:

https://news.ycombinator.com/item?id=39871735

As it stands I really have no idea why the service manager has not been split off from PID 1. Maintainer said that PID 1 was "different" but didn't really elaborate. Can't find much reliable information about said differences either. Do you know?

I have no idea, lol. Maybe the signal handling behavior? You can't signal PID1 (unless the process has installed its own signal handler for that signal). Even SIGKILL won't usually work.

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.

Yeah the signal handling thing is true, PID 1 is the only process that can handle or mask SIGKILL, maybe even SIGSTOP. The systemd manual documents its handling of a ton of signals but there's nothing in there about either of those otherwise unmaskable signals. So I don't really see how systemd is "relying" on anything. It's not handling SIGKILL, is it?

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.

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

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.

> If your service manager crashes an automatic reboot is nice, in a way.

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