[Spread-users] pid and process control

[Dave Koberstein]

Ok - making more sense.

Fork/exec would be the conventional way to do it.  The trouble you are 
having is that spread doesn't exit at any point to provide a success 
return code so you'll never get one.  That's the reason in the shell 
commands that & gives it's own return code.  It did a fork/exec and 
didn't expect to have a return code to offer because the new thread 
isn't expected to exit.

exec does return a return code for system type errors (executable not 
found and such).  So you'll get some errors that way.  But the only want 
to tell that spread didn't exit of it's own accord (didn't like a config 
file, etc) is to check if it's still running.

The & and fork/exec also offer another problem.  If you start other 
services immediately after forking spread, say in a startup script, the 
services might not connect because spread might not be ready.  I've 
found a sleep 5 to work.  But as you say, brittle.  Probably better if 
my clients stay up and try periodically for ever.  My clients do handle 
a spread that stops and restarts.  The startup is on my list to go back 
and make more robust.  I'd appreciate learning what you find about best 
practice.

Davek

Michael Peters wrote:
> Dave Koberstein wrote:
>> Just a thought ... if you are using & in your perl/system call, try 
>> instead using fork/exec.
>
> exec() won't work because I can't get the return value from that. 
> fork() has a similar problem. If I fork and then do the system() call 
> without the "&" it never returns. If I use the "&" it's the same 
> problem as above. I guess I could do something like fork and then exec 
> in the child. Wait a couple seconds in the parent then check that my 
> child hasn't died... Just seems a little messy.
>
> Any other ideas?
>