As I indicated in my original post, I am writing a general purpose library for interacting with the process table. Perhaps you assumed I am trying to make sure there is only one instance of a process running? Even if that is what I was attempting to do (it isn't), using locks on a file have their own limitations. For instance, on most *nix platforms the lock is advisory and not enforced by the kernel. Additionally, you can delete a locked file.

Again, I need to be able to answer the questions:

• Is this specific script at this absolute path currently running?
• Is there a process in the process table with X in the command line arguments?

I would agree with sundialsvc4 that a mechanism where a script writes to a file at startup, and cleans up when it exits, is the way to go. Write the PID to the file. We generally use this mechanism to ensure only one instance of a program is running, but there is nothing to stop you putting multiple PIDs in the file. Either name the PID file according to some convention (e.g. replace "/" in the script path with "-" or some such), or for full generality create a directory tree, on the fly, matching the script path (e.g. a script "/abc/xyz/foo" having PID file "/tmp/pidfiles/abc/xyz/foo.pid").

File locking in this scenario is required, and I don't really understand your concerns about this--after all the script only needs to cooperate with other identical instances of itself, all of which would use the convention of using flock on the PID file. Or put your PIDs in a database.

The only other comment I would make is that you need to handle the case where a script dies before it can remove its PID from the PID file. So check whether a PID is still in use when you start up new instance of a script, and if not, clean up that entry.

philipbailey,
I truly don't mean to be rude but what are you talking about? You seem to be assuming I am trying to do something I am not despite me saying very clearly this is not about trying to ensure only one copy of a script is running or not. This is about providing a consistent way of interacting with the process table. Are you saying I should go to every vendor of every application to include the OS and tell them that they have to use a lock file so my utility can know if you are running or not?

If you really want to have a discussion about the merits of using a pid file for ensuring only one copy of an "in-house" script is only running once - I would be happy to in another thread. The fact that you indicate to check to see if the PID is still in use shows me you don't understand the problem (how do I distinguish between some other process that happened to get my old PID versus my script still running).

Cheers - L~R