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