[aclug-L] Re: odd shell question

[Tom Hull <thull@xxxxxxxxxxx>]

Jeff wrote:
> 
> > Jeff: "I was expecting ssh-agent to run "bash --login""
> 
> It was. It exec'd ssh-agent correctly, and it exec'd bash
> correctly, but bash barfs soon after with:
> 
>      0.000126 rt_sigaction(SIGTTIN, {SIG_DFL}, {SIG_IGN}, 8) = 0
>      0.000141 kill(0, SIGTTIN)          = 0
>      0.000118 --- SIGTTIN (Stopped (tty input)) ---
> 
> repeated over and over.  I'm wondering if it doesn't like the idea
> that ssh-agent fed it input?  (The shell variables).  Anyway, it
> gets stuck in this loop, never exiting.

i've seen ksh get into degenerate loops like this. looks like bash
isn't immune, either. on some level this has to be a bash bug (dumb
thing should get a clue after a few million loops, anyway). however,
that that doesn't mean you aren't doing something wrong.

SIGTTIN is normally sent to a background process which attempts
to read from its tty. (in the good old days, the input would be
distributed by chance, which would produce all sorts of amusing
results.)

if i read the trace correctly, it says that bash got a SIGTTIN,
and decided to broadcast it to its process group (i guess to
spread the misery around). don't know why it would do that, but
that's probably not the problem. (though it could be a bash bug.)

more likely, the problem is that bash has been backgrounded,
either by eval or ssh-agent; more precisely, it has lost its
tty, which happens, e.g., when login shells do setpgrp().

i the wild guess department, i wonder what a </dev/null would do.
the code should still read the passwd from /dev/tty (before it
does a setpgrp); beyond that do you need stdin if you're going
to attach a socket later?

-- 
/*
 *  Tom Hull * thull@xxxxxxxxxxx * http://www.ocston.org/~thull/
 */