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

Limbic~Region, members of PerlMonks can only respond to the requirements you have given. You start by saying I am currently working on building a library of tools so that others at the office can more easily write robust scripts. That sounds like you are only handling in-house code, which would be amenable to the suggestions you have been given. Now you say every vendor of every application. Which is it?

You also say you seem to be assuming I am trying to do something I am not. Well perhaps you should more clearly state what it is that you need. But if you read what I said carefully, I have suggested that you could put multiple PIDs in a file relating to each script, allowing you to keep track of as many as you want.

On the scenario of a script (1) dying without cleaning up the relevant PID entry and (2) another process with the same PID coming into existence, sure that's possible. So, also check the command line for that PID when deciding whether to clean it up (or the owner of the process or GID or the parent PID or all of the above). That is more certain than only checking the contents of the process table.