Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^2: Working With The Process Table (AIX)

by Limbic~Region (Chancellor)
on Aug 05, 2011 at 15:16 UTC ( [id://918802]=note: print w/replies, xml ) Need Help??

in reply to Re: Working With The Process Table (AIX)
in thread Working With The Process Table (AIX)

Maybe I can do what another way?

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?

Cheers - L~R

  • Comment on Re^2: Working With The Process Table (AIX)

Replies are listed 'Best First'.
Re^3: Working With The Process Table (AIX)
by philipbailey (Curate) on Aug 05, 2011 at 18:18 UTC

    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/").

    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.

      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.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://918802]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-04-18 14:41 GMT
Find Nodes?
    Voting Booth?

    No recent polls found