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