On Tue, Jun 25, 2019 at 07:11:50PM +0300, Arseny Maslennikov wrote: > This matches the behaviour of other Unix-like systems that have SIGINFO > and causes less harm to processes that do not install handlers for this > signal, making the keyboard status character non-fatal for them. > > This is implemented with the assumption that SIGINFO is defined > to be equivalent to SIGPWR; still, there is no reason for PWR to > result in termination of the signal recipient anyway — it does not > indicate there is a fatal problem with the recipient's execution > context (like e.g. FPE/ILL do), and we have TERM/KILL for explicit > termination requests. So this is a consequence of trying to overload SIGINFO with SIGPWR. At least on some legacy Unix systems, the way SIGPWR worked was that init would broadcast SIGPWR to all userspace process (with system daemons on an exception list so they could get shutdown last). Applications which didn't have a SIGPWR handler registered, would just exit. Those that did, were expected to clean up in preparation with the impending shutdown. After some period of time, then processes would get hard killed and then system daemons would get shut down and the system would cleanly shut itself down. So SIGPWR acted much like SIGHUP, and that's why the default behavior was "terminate". Now, as far as I know, we've not actually used in that way, at least for most common distributions, but there is a sane reason why things are they way there are, and in there are people who have been using SIGPWR the way it had originally been intended, there is risk in overloading SIGINFO with SIGPWR --- in particular, typing ^T might cause some enterprise database to start shutting itself down. :-) (In particular it might be worth checking Linux ports of Oracle and DB2.) - Ted
