Sun, 1 Apr 2001 23:32:49 -0400
|
On Sat, 31 Mar 2001 09:26:53 EST, "Glenn A. Malling" <[log in to unmask]> said:
> [log in to unmask] said:
>
> > OK.. The problem is that 'init' thinks that the 'lsv' process has
> > exited. You *might* try using this instead, and see if the lack of
> > redirection starts making it work:
>
> > ls:235:respawn:/home/listserv/go bg
>
> I think it's the "bg" that's the problem. When LISTSERV goes into
> the background it disconnects from its controlling pty and init
No, it's the redirection that does it.
listserv:2:respawn:/home/listserv/go bg
Been using that for literally years.
Things launched by init don't HAVE a control terminal unless they
aquire one by opening /dev/console or something. That's why they show a
'?' for the terminal in 'ps'. This is actually very important...
Here's what's REALLY happening:
'go' is launched by init with no controlling terminal. It opens
/dev/console to do the redirection. *poof* it has a control terminal now.
'go' gets down to lines 81-83, and doesn't set the variable $lsvexec
because it has a control terminal (thus 'tty -s' returns 0). So we
get down to line 86 and instead of doing 'exec sh -c', it just does an
'sh -c'.
This is crucial, because this means that the command gets done in a
child shell. So when the child shell launches it into the background,
*this* shell exits, and 'init' says "oh, it finished, we need to respawn".
If you don't aquire a control terminal, tty -s return 1, and we end up
doing 'exec sh -c...' so the *current* process backgrounds itself - and
this means that init doesn't see *this* process exit, so it doesn't respawn.
Clear now? ;)
/Valdis
|
|
|