Fair enough. I'll abandon the signals part of this and just send out the VSTATUS/Control-T part, after I address some comments from Greg. Thanks. On Tue, Jan 4, 2022 at 12:52 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote: > > I dug through the previous conversations and there is a little debate > > about what makes sense for SIGPWR to do by default. Alan Cox remembered > > SIGPWR was sent when the power was restored, so ignoring SIGPWR by > > default made sense. Ted Tso pointed out a different scenario where it > > was reasonable for SIGPWR to be a terminating signal. > > > > So far no one has actually found any applications that will regress if > > SIGPWR becomes ignored by default. Furthermore on linux SIGPWR is only > > defined to be sent to init, and init ignores all signals by default so > > in practice SIGPWR is ignored by the only process that receives it > > currently. > > As it turns out, systemd does *not* ignore SIGPWR. Instead, it will > initiate the sigpwr target. From the systemd.special man page: > > sigpwr.target > A special target that is started when systemd receives the > SIGPWR process signal, which is normally sent by the kernel > or UPS daemons when power fails. > > And child processes of systemd are not ignoring SIGPWR. Instead, they > are getting terminated. > > <tytso@cwcc> > 41% /bin/sleep 50 & > [1] 180671 > <tytso@cwcc> > 42% kill -PWR 180671 > [1]+ Power failure /bin/sleep 50 > > > Where I saw the last conversation falter was in making a persuasive > > case of why SIGINFO was interesting to add. Given a world of ssh > > connections I expect a persuasive case can be made. Especially if there > > are a handful of utilities where it is already implemented that just > > need to be built with SIGINFO defined. > > One thing that's perhaps worth disentangling is the value of > supporting VSTATUS --- which is a control character much like VINTR > (^C) or VQUIT (control backslash) which is set via the c_cc[] array in > termios structure. Quoting from the termios man page: > > VSTATUS > (not in POSIX; not supported under Linux; status > request: 024, DC4, Ctrl-T). Status character (STATUS). > Display status information at terminal, including state > of foreground process and amount of CPU time it has > consumed. Also sends a SIGINFO signal (not supported on > Linux) to the foreground process group. > > The basic idea is that when you type C-t, you can find out information > about the currently running process. This is a feature that > originally comes from TOPS-10's TENEX operating system, and it is > supported today on FreeBSD and Mac OS. For example, it might display > something like this: > > load: 2.39 cmd: ping 5374 running 0.00u 0.00s > > The reason why SIGINFO is sent to the foreground process group is that > it gives the process an opportunity print application specific > information about currently running process. For example, maybe the C > compiler could print something like "parsing 2042 of 5000 header > files", or some such. :-) > > There are people who wish that Linux supported Control-T / VSTATUS, > for example, just last week, on TUHS, the Unix greybeards list, there > were two such heartfelt wishes for Control-T support from two such > greybeards: > > "It's my biggest annoyance with Linux that it doesn't [support > control-t] > - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024849.html > > "I personally can't stand using Linux, even casually for a very > short sys-admin task, because of this missing feature" > - https://minnie.tuhs.org/pipermail/tuhs/2021-December/024898.html > > I claim, though, that we could implement VSTATUS without implenting > the SIGINFO part of the feature. Previous few applications *ever* > implemented SIGINFO signal handlers so they could give status > information, it's the hard one, since we don't have any spare signals > left. If we were to repurpose some lesser used signal, whether it be > SIGPWR, SIGLOST, or SIGSTKFLT, the danger is that there might be some > userspace program (such as a UPS monitoring program which wants to > trigger power fail handling, or a userspace NFSv4 process that wants > to signal that it was unable to recover a file's file lock after a > server reboot), and if we try to take over the signal assignment, it's > possible that we might get surprised. Furthermore, all of the > possibly unused signals that we might try to reclaim terminate the > process by default, and SIGINFO *has* to have a default signal > handling action of Ignore, since otherwise typing Control-T will end > up killing the current foreground application. > > Personally, I don't care all that much about VSTATUS support --- I > used it when I was in university, but honestly, I've never missed it. > But if there is someone who wants to try to implement VSTATUS, and > make some Unix greybeards happy, and maybe even switch from FreeBSD to > Linux as a result, go wild. I'm not convinced, though, that adding > the SIGINFO part of the support is worth the effort. > > Not only do almost no programs implement SIGINFO support, a lot of CPU > bound programs where this might be actually useful, end up running a > large number of processes in parallel. Take the "parsing 2042 of 5000 > header files" example I gave above. Consider what would happen if gcc > implemented support for SIGINFO, but the user was running a "make -j > 16" and typed Control-T. The result would be chaos! > > So if you really miss Control-T, and it's the only thing holding back > a few FreeBSD users from Linux, I don't see the problem with > implementing that part of the feature. Why not just do the easy part > of the feature which is perhaps 5% of the work, and might provide 99% > of the benefit (at least for those people who care). > > > Without seeing the persuasive case for more signals I have to say that > > adding more signals to the kernel sounds like a bad idea. > > Concur, 100%. > > - Ted
