On 11/29/16 1:32 AM, Pas wrote:
> Hello,
>
> Thank you for the very fast reply, though I'd like to shamelessly ask
> for more bits of your time.
>
> I've strace'd all the involved processes (as far as I know), and all
> were just getting the SIGTTINs, no one was sending SIGCONTs (
> http://i.imgur.com/n5bUQVM.png - 25799 a bash process, and even the
> bash (pid 7026) not in the picture that was just doing pselect(...) on
> the terminal, the atom processes, and the bash process that goes
> haywire ).
The original strace from the stackoverflow post shows pretty clearly that
SIGTTIN is being ignored:
rt_sigaction(SIGTTIN, {SIG_IGN, [], SA_RESTORER, 0x7fd5f6989d80}, {SIG_DFL,
[], SA_RESTORER, 0x7fd5f6989d80}, 8) = 0
And it looks like that is the original signal disposition for SIGTTIN.
>
> Also, if the default behavior for SIGTTIN is to stop, why bash isn't
> stopping? How come the kernel isn't stopping it either? (And then if
> not, where's the read() that should return EIO?)
You can block or ignore SIGTTIN, and you can start bash wih it blocked
or ignored. That will defeat bash's attempts to stop itself by sending
SIGTTIN. The loop in the stackoverflow post shows that the original
disposition for SIGTTIN is SIG_IGN, but I don't know why the process
isn't being stopped after the SIG_DFL/kill steps.
No read happens until bash determines that it's in the terminal's
foreground process group. This is all part of trying to get job control
initialized, well before the shell attempts to read from the terminal.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
