3 ms·

> By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1 Except it literally is. I once had a systemd system sudden

> By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1 Except it literally is. I once had a systemd system suddenly refuse to boot (kernel panic because PID1 crashed or so) after a Debian upgrade, which I was able to resolve by... wait for it... making /etc/localtime not be a symlink. Why does a failure doing something with the timezone make you unable to boot your system? What is it even doing with the timezone? What is failing about it? Who knows, good luck strace'ing PID1!

matheusmoreira 3y ago
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 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?
- Repulsion9513 3y ago
  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.
  - matheusmoreira 3y ago
    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 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#L2397 https://github.com/systemd/systemd/blob/main/src/core/main.c... https://github.com/systemd/systemd/blob/main/src/basic/process-util.c#L2011-L2027 https://github.com/systemd/systemd/blob/main/src/basic/proce... https://github.com/systemd/systemd/blob/main/src/basic/process-util.c#L1996-L2009 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/nspawn-stub-pid1.c#L52 https://github.com/systemd/systemd/blob/main/src/nspawn/nspa... It's only being used inside namespaces though! Why? No idea.
    - Repulsion9513 3y ago
      > 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.
      - matheusmoreira 3y ago
        > 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...

matheusmoreira 3y ago

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

Repulsion9513 3y ago
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.
- matheusmoreira 3y ago
  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 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#L2397 https://github.com/systemd/systemd/blob/main/src/core/main.c... https://github.com/systemd/systemd/blob/main/src/basic/process-util.c#L2011-L2027 https://github.com/systemd/systemd/blob/main/src/basic/proce... https://github.com/systemd/systemd/blob/main/src/basic/process-util.c#L1996-L2009 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/nspawn-stub-pid1.c#L52 https://github.com/systemd/systemd/blob/main/src/nspawn/nspa... It's only being used inside namespaces though! Why? No idea.
  - Repulsion9513 3y ago
    > 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.
    - matheusmoreira 3y ago
      > 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...