Messages in this thread | | | Date | Wed, 26 Jun 2019 16:49:41 +0300 | From | Arseny Maslennikov <> | Subject | Re: [PATCH v2 4/7] linux/signal.h: Ignore SIGINFO by default in new tasks |
| |
On Tue, Jun 25, 2019 at 05:32:15PM -0400, Theodore Ts'o wrote: > 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.
Pretty much.
> 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. :-)
Only if that enterprise database: 1) has a controlling terminal (a strange condition for a daemon, IMHO) 2) that terminal has the status character set in the struct termios.
> > (In particular it might be worth checking Linux ports of Oracle and > DB2.)
A quick google got me this document: https://docs.oracle.com/cd/B28359_01/server.111/b32009.pdf It only ever mentions CHLD, CONT, INT, PIPE, TERM, URG and IO.
I have no real experience with neither DB2 nor Oracle DB, though, and no way to get hold of that kind of software, so I don't know where to look further. If we'd like to be really sure no one's hurt we'll need someone with actual expertise here.
[unhandled content-type:application/pgp-signature] | |