* https://news.ycombinator.com/item?id=8904429
* http://unix.stackexchange.com/a/197472/5132
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, 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?
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) and its TODO list.
I recommend some manual reading. (-:
SIGWINCH for a keyboard request is a thing that I did not know about, yes. But this is opt-in functionality for any process that has any VT open and is suitably privileged, and it is simply traditional for init to call ioctl(0, KDSIGACCEPT, SIGWINCH). Any process can request this, not just init; any signal can be used, not just SIGWINCH. And by default, no signal gets sent, neither to init nor to any other process. So init does not need to handle it.
(This of course leaves aside the question of whether anyone uses this functionality. How many users who are not init system developers know about this? And how many people have machines with physical keyboards that are not just running some window system that puts the keyboard in raw mode, anyway?)
See https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/k... and L593-602 (initialized to 0 and disabled by default), https://github.com/torvalds/linux/blob/v4.7/drivers/tty/vt/v... (KDSIGACCEPT ioctl allows any suitably privileged process to request this), and http://www.fifi.org/doc/console-tools-dev/examples/spawn_log... (a separate daemon for doing this - via SIGHUP, incidentally - which says, "Note: this functionality has become part of init", implying it was originally not part of init!).
SIGINT on Ctrl-Alt-Del (if reboot(LINUX_REBOOT_CMD_CAD_OFF) has been called), and SIGPWR on power failure from the two drivers that implement it, are sent via the kill_cad_pid() function. This does default to pid 1, but that's just a default. And it's very easy to change that setting in userspace; it's a sysctl, /proc/sys/kernel/cad_pid.
See https://github.com/torvalds/linux/blob/v4.7/init/main.c#L998, which defaults cad_pid to init, and https://github.com/torvalds/linux/blob/v4.7/kernel/sysctl.c#..., the sysctl implementation.
The two drivers that implement SIGPWR, incidentally, are the S390 NMI handler and the SGI SN Platform's system controller driver, both of which I'm pretty sure see no use today. It's usually sent by a userspace process these days, which again could just choose to not use signals.
So none of the signals you've mentioned are pid 1's responsibility, They are traditionally pid 1's responsibility, yes. But those are two very different things, especially if we're talking about using PR_SET_CHILD_SUBREAPER to move all the interesting work out of pid 1.
The remainder of the signals handled by sysvinit, finit, runit, and nosh are all generated by userspace, and minit handles no other signals. And not all of these init systems bother to call KDSIGACCEPT.
I recommend being less condescending, especially if you're going to be wrong. (-: