HP3000-L Archives

December 2000, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Danny A. van Delft" <[log in to unmask]>
Reply To:
Danny A. van Delft
Date:
Mon, 11 Dec 2000 07:46:21 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
On Fri, 8 Dec 2000 12:45:16 -0600 (Central Standard Time), Mark Bixby
<[log in to unmask]> wrote:

>"Danny A. van Delft" wrote:
>>
>> On Tue, 5 Dec 2000 14:01:18 -0600 (Central Standard Time), Mark Bixby
>> <[log in to unmask]> wrote:
>>
>> <snip>
>>
>> >It would also normally be an exercise for the reader to use the shell to obtain
>> >pids without using ps for things that don't write their pids to disk files, but
>> >since I have some time today to explain, here's the magic shell incantation:
>> >
>> >        serverprogram serverparms &; echo $! >/tmp/server.pid; wait
>> >
>> >You invoke the server program and pass any expected parameters, then follow the
>> >last parameter (if any) with an ampersand (&).  The ampersand tells the shell
>> >to run the command asynchronously, kind of like MPEX ;GOON (IIRC).  The $!
>> >variable contains the pid of the last asynchronous command, so we echo it to a
>> >disk file suitable for later killing, i.e. kill `cat /tmp/server.pid`.  Lastly,
>>
>> A problem with this approach is that if "serverprogram" is already
>> running, you've now zapped its pid in the pid-file and made it
>> un-killable by the "`cat pid-file` technique.
>
>You're absolutely correct.  While the intent of my example was to demonstrate
>how you can capture the pid of a process you've just launched from the shell,
>you would have to do additional checking to prevent overwriting the previous
>pid if the server was being started before any previous instances had
>terminated.
>

Test you must indeed. However, there is no way you can reliably test
for this condition using just the shell. You need an atomic test&set
method to prevent race conditions, and the shell alone doesn't provide
one. The idiom I use when trying to start up a server and record its
pid for later killing (ahum, gently try to persuade it to terminate)
is:

- try to get hold of a semaphore. I generally try to lock a file
exclusive, with or without blocking. Don't release the semaphore.
- iff succes, then proceed with  the server and record its pid into
the pid-file, otherwise just give up (with an appropriate error)

The semphore should ideally be released automatically when the process
terminates, as the exclusive lock does, per compliments of the
operating system.
This way you know for certain that whatever pid is recorded into the
pid-file it is either from a running server or from a no longer active
server, and there is no chance of losing the pid of a running server.

...
>>
>Fortunately I think most Internet servers (including sendmail, apache, bind)
>already write their own pid files, so adding this type of code yourself should
>be unnecessary.
>
>For servers that do not do this, download the source code, add the code
>yourself, and submit your changes back to the official developers.
>

Agreed, that is always the best way to go for available sources. Just
be sure to use the correct method.
Danny A. van Delft   [log in to unmask]

ATOM RSS1 RSS2