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

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

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

Replies are listed 'Best First'.
Re^5: Working With The Process Table (AIX) by philipbailey (Curate) on Aug 05, 2011 at 21:27 UTC
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.	[reply]
Re^6: Working With The Process Table (AIX) by Limbic~Region (Chancellor) on Aug 06, 2011 at 00:27 UTC
philipbailey, We seem to be speaking past one another. At no point have I said the in-house developed script needs to know if itself is running. While the scripts my co-workers may write are in-house scripts, they will be interacting with the process table and any process that may be running there. One (of many) features I would like this library to have is the ability to answer questions like: Is /usr/bin/hello running (even if it may look like sh ../hello in the process table) Of the bazillion /usr/bin/java processes that are running, are any running with command line arguments that have the max heap space set to above 3GB I assure you that I read your post carefully and I am sorry if I came across at not being appreciative of your response. Perhaps I am too close to the problem. To try and be clearer - the library is a general purpose way for in-house developed scripts to interact with the process table - even when those processes are not in-house. Cheers - L~R	[reply]
Re^7: Working With The Process Table (AIX) by philipbailey (Curate) on Aug 06, 2011 at 09:08 UTC
Limbic~Region, thanks for your more considered reply, and I'm sorry that I partially misunderstood your situation. But I do have some insight into your problem, as we too have a number of other people's Java processes running. In our case, however, we control every aspect of the startup of a customer's code, including the JVM arguments. So we already know what heap size is being used, for example. We are also able to use Unix usernames with enough granularity to identify processes, perhaps in combination with some other piece of data: the PID or part of the command line, with complete certainty. We also always wrap vendor products' code with our own scripts. Of course, I can't tell whether any of the above can be applied to your situation, but I wish you luck in resolving it.	[reply]