Hello all,

I develop an ERP application that runs on a number of *nix flavors. This application had been around for quite a number of years.

As part of the application launch, we do a check for a background process using the following command:

ps -ef | grep -v grep | grep mi\/ba | grep databasename | wc -l

This returns the number of processes running (should always be either 1 or 0). If the process is running, it's should be owned by root.

We've used this command for quite a number of years with no problem. Now, for some unknown reason, at one of our customers' sites (AIX 5.1), the command is returning zero even if the process is running. This causes a second background process to start, and usually by a user other than root.

We took the command string and put it into a shell script that just repeated over and over. In 8500 attempts, the command failed about 5 times. That doesn't seem like a lot, but just one causes an extra process to start.

If anyone has a possible as to the cause or how to correct, I would be very appreciative.

Thanks,

JL

You could create a lock file, by adding something like the following to the beginning of the background script:
if [ -r lockfile.pid ]
then
echo "Background Process already running "
exit 1
else
echo $$ >lockfile.pid
fi

Then at the end of the background process, and in the system start up process add:
rm lockfile.pid


Then have the foreground application test for the existence of the lock file.

As for why the ps command doesn't always work, is it possible that the pid number disappears from the process list when the process is swapped out.

jgt,

Thanks for the reply.

Using a lock file is one possibility, but I was hoping that I'd be able to resolve the ps issue. Using a lock file could put more burdon on our customers if, for example, the background process dies or is killed but the application is still running. In that case, the user would need to get to the os and delete the file manually. Not all of our customers' are technically adept. Not out of the question, but probably a last resort.

As for your comment:

Were you making a statement or asking a rhetorical question

JL

I know nothing about AIX. But some man pages on the web for "ps" say, "Programs swapped out to disk will be shown without command line arguments, and unless the c option is given, in brackets."

It's not clear if you are grepping for command line arguments. If you are, and the program is swapped out and the AIX ps is subject to the limitation, it could be failing on the grep for command line arguments.

kahuna,

Yes, the grep is a command line argument. The process itself can be running quite a number of times; it's the main process for the application and each usr who logs in uses the same program.

I guess I'll need to look at alternatives like the lock file. If AIX is swapping out that process, there's not too much I can do. It is curious that we've never, in over 10 years, see this problem. I wonder if the customer in this case changed some parameters that caused AIX to swap out processes more often.

Thanks.

JL

OK. You might want to first verify that the AIX ps works this way. I don't know that to be true.

I understand. I don't either

Thanks.