|
Home > Archive > Unix Programming > November 2005 > Starting a process inside a shell script
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Starting a process inside a shell script
|
|
| mobenoua 2005-11-23, 5:54 pm |
| How can one invokes a c++ process to start from a shell script and wait
until
the process has started before proceeding to execute the next line in
the shell and
without calling wait or sleep to wait for the process to start.
| |
| Eric Sosman 2005-11-23, 5:54 pm |
|
mobenoua wrote On 11/23/05 16:33,:
> How can one invokes a c++ process to start from a shell script and wait
> until
> the process has started before proceeding to execute the next line in
> the shell and
> without calling wait or sleep to wait for the process to start.
What do you mean by "wait until the process has started?"
How much progress must the new process make before you decide
it has switched from "starting" to "started?" What external
sign is there that this switchover has occurred?
(Of course, one way to be sure the process has "started"
is to wait until it finishes; all "start-up" activities will
have completed by then ;-)
--
Eric.Sosman@sun.com
| |
| mobenoua 2005-11-23, 5:54 pm |
| This is a very short example of a script
#!/bin/sh
mycommand="my c++ program"
$mycommand
echo my program has started
I don't want to run the echo command in the script until my program has
fully started. My program is a server which will then waits for
requests
from clients through a socket. I can say that the server has fully
started
when it gets to accept system call on the socket.
| |
| Pascal Bourguignon 2005-11-23, 5:54 pm |
| "mobenoua" <mobenoua@hotmail.com> writes:
"mobenoua" <mobenoua@hotmail.com> writes:
> This is a very short example of a script
>
> #!/bin/sh
> mycommand="my c++ program"
> $mycommand
> echo my program has started
>
> I don't want to run the echo command in the script until my program has
>
> fully started. My program is a server which will then waits for
> requests
> from clients through a socket. I can say that the server has fully
> started
> when it gets to accept system call on the socket.
Then try to connect to the server process. When you can, it means the
server is ready.
[pjb@thalassa pjb]$ echo QUIT | netcat larissa 110 >/dev/null ; echo $?
0
[pjb@thalassa pjb]$ echo QUIT | netcat localhost 110 >/dev/null ; echo $?
1
It works better if you can send a command to the server.
$server &
while [ ! (echo QUIT | netcat localhost $port >/dev/null) ] ; do
sleep 1
done
echo "$server is ready."
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
| |
| Gordon Burditt 2005-11-23, 5:54 pm |
| >This is a very short example of a script
>
>#!/bin/sh
>mycommand="my c++ program"
>$mycommand
>echo my program has started
>
>I don't want to run the echo command in the script until my program has
>
>fully started.
There is no conventional definition of what it means for a
program to be "fully started", short of "has terminated".
>My program is a server which will then waits for
>requests
>from clients through a socket. I can say that the server has fully
>started
>when it gets to accept system call on the socket.
Ok, then keep trying to connect to the socket. When you succeed
(assuming TCP), it's "fully started". For UDP, you need to actually
exchange messages, as connecting a UDP socket to a server that never
existed takes almost no time.
I presume you have a client for this server. Write a specialized
client which repeatedly tries to connect to the server, and when
it succeeds, send it a trivial command (like "VERSION" or "QUIT"),
wait for a response, and exit successfully. Your client should
also allow for the possibility that the server will fail to start
at all, and eventually time out and exit, indicating failure.
The above client may also be very useful for monitoring whether
the server is *still* working.
Gordon L. Burditt
|
|
|
|
|