undefined | Better HN

0 pointsRepulsion95131y ago0 comments

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

0 comments

matheusmoreira1y 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

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?

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

matheusmoreira1y 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

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

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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

matheusmoreira1y ago

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

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

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

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

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

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.

1 more reply

j / k navigate · click thread line to collapse