5 ms·

The Unix philosophy is most applicable in user space. It's a philosophy not a law. I didn't say Systemd was bad just that it doesn't observe the Unix philosop

The Unix philosophy is most applicable in user space. It's a philosophy not a law. I didn't say Systemd was bad just that it doesn't observe the Unix philosophy. Crashing an init process is a very bad thing, is it not? Wouldn't less surface area be a better approach?

deleted 10y ago
[deleted]
geofft 10y ago
Yes, I argued in another comment that it would be a good idea to split systemd into two processes, where PID 1 does nothing other than reap children, send info to PID 2 actual systemd, and restart PID 2 if needed. But it seems to make sense for PID 2 to be as monolithic as systemd currently is (which is not very monolithic; udev, journald, D-Bus, etc. are separate daemons).
- fridsun 10y ago
  You just described how daemontools family works. They are less monolithic than systemd because they didn't subsume udev.
- JdeBP 10y ago
  That's a common misconception. The major task of process #1 with modern kernels is not, ironically, reaping children but receiving signals. Reaping orphaned children can be, and with several softwares is, the job of other processes. * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132 * https://news.ycombinator.com/item?id=8384251 https://news.ycombinator.com/item?id=8384251 * http://unix.stackexchange.com/a/177361/5132 http://unix.stackexchange.com/a/177361/5132
  - geofft 10y ago
    That makes no sense. Who's sending SIGWINCH to pid 1? Is it in a tty? Why is it in a tty? Why does it care about the size of its window? It is true that the userspace helper programs of some init system suites, such as sysvinit's telinit, work by sending signals to pid 1. But 1) they send signals to pid 1 because pid 1 is the service manager, not because it's the system manager, and 2) they could do something else other than sending signals (like sending D-Bus messages). The choice to use signals is a design decision of the init system suite, and not a part of the inherent requirements of being pid 1. It is also true that with prctl(PR_SET_CHILD_SUBREAPER) you can move reaping away from pid 1. But at that point, the proper function of pid 1 is nothing, except perhaps to respawn pid 2 if it wants to. And as I argued in the other comment in this thread https://news.ycombinator.com/item?id=12600734 https://news.ycombinator.com/item?id=12600734, that's silly and you should just make the kernel do it. I don't see any explanation in any of those links, or the things they link to, about why pid 1 is receiving signals. You claim twice that SIGINT, SIGPWR, and SIGWINCH are things that pid 1 can receive, but I have no idea why it might receive them. Can you explain?
    - JdeBP 10y ago
      It's explained two times over, and they are indeed system state controls, not service state controls. You are exemplifying the people with off-the-top-of-the-head designs for init that I mentioned. The signals to process #1 from the kernel are rarely included, or even thought of, in such designs; despite the fact that they are the things that a process #1 program cannot escape and the child reaping is actually the least of its work and the thing that it can mostly escape. Here you are with yet another off-the-top-of-the-head design being thrashed out in a discussion forum, and you have not even encountered this stuff to know that a design has to include it, as evidenced by the questions about TTYs and windows. As I said, go and look at many actual process #1 programs, such as Gerrit Pape's runit, Felix von Leitner's minit, and the system-manager program from the nosh package. They all have to handle these signals, and they all do. Don't repeat ... ahem! ... some other people's mistake of not learning about existing softwares and mechanisms. The nosh system-manager and systemd both discuss them in their manual pages. They both have an explicit list of signals and what they trigger. The manual for /etc/inittab in van Smoorenburg init also discusses these signals and what they are, as do the manual for Joachim Nilsson's finit (http://troglobit.com/finit.html http://troglobit.com/finit.html) and its TODO list. I recommend some manual reading. (-:

deleted 10y ago

[deleted]

geofft 10y ago

Yes, I argued in another comment that it would be a good idea to split systemd into two processes, where PID 1 does nothing other than reap children, send info to PID 2 actual systemd, and restart PID 2 if needed. But it seems to make sense for PID 2 to be as monolithic as systemd currently is (which is not very monolithic; udev, journald, D-Bus, etc. are separate daemons).

fridsun 10y ago
You just described how daemontools family works. They are less monolithic than systemd because they didn't subsume udev.
JdeBP 10y ago
That's a common misconception. The major task of process #1 with modern kernels is not, ironically, reaping children but receiving signals. Reaping orphaned children can be, and with several softwares is, the job of other processes. * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132 * https://news.ycombinator.com/item?id=8384251 https://news.ycombinator.com/item?id=8384251 * http://unix.stackexchange.com/a/177361/5132 http://unix.stackexchange.com/a/177361/5132
- geofft 10y ago
  That makes no sense. Who's sending SIGWINCH to pid 1? Is it in a tty? Why is it in a tty? Why does it care about the size of its window? It is true that the userspace helper programs of some init system suites, such as sysvinit's telinit, work by sending signals to pid 1. But 1) they send signals to pid 1 because pid 1 is the service manager, not because it's the system manager, and 2) they could do something else other than sending signals (like sending D-Bus messages). The choice to use signals is a design decision of the init system suite, and not a part of the inherent requirements of being pid 1. It is also true that with prctl(PR_SET_CHILD_SUBREAPER) you can move reaping away from pid 1. But at that point, the proper function of pid 1 is nothing, except perhaps to respawn pid 2 if it wants to. And as I argued in the other comment in this thread https://news.ycombinator.com/item?id=12600734 https://news.ycombinator.com/item?id=12600734, that's silly and you should just make the kernel do it. I don't see any explanation in any of those links, or the things they link to, about why pid 1 is receiving signals. You claim twice that SIGINT, SIGPWR, and SIGWINCH are things that pid 1 can receive, but I have no idea why it might receive them. Can you explain?
  - JdeBP 10y ago
    It's explained two times over, and they are indeed system state controls, not service state controls. You are exemplifying the people with off-the-top-of-the-head designs for init that I mentioned. The signals to process #1 from the kernel are rarely included, or even thought of, in such designs; despite the fact that they are the things that a process #1 program cannot escape and the child reaping is actually the least of its work and the thing that it can mostly escape. Here you are with yet another off-the-top-of-the-head design being thrashed out in a discussion forum, and you have not even encountered this stuff to know that a design has to include it, as evidenced by the questions about TTYs and windows. As I said, go and look at many actual process #1 programs, such as Gerrit Pape's runit, Felix von Leitner's minit, and the system-manager program from the nosh package. They all have to handle these signals, and they all do. Don't repeat ... ahem! ... some other people's mistake of not learning about existing softwares and mechanisms. The nosh system-manager and systemd both discuss them in their manual pages. They both have an explicit list of signals and what they trigger. The manual for /etc/inittab in van Smoorenburg init also discusses these signals and what they are, as do the manual for Joachim Nilsson's finit (http://troglobit.com/finit.html http://troglobit.com/finit.html) and its TODO list. I recommend some manual reading. (-: