grep help

[GBR]

#!/bin/sh
set -x
run=$(ps -ef | grep ${0} | grep -v grep | wc -l)
echo $run

The above command on server 1 gives the following output:

+ + ps -ef
+ grep ./test
+ wc -l
+ grep -v grep
run=1
+ echo 1
1

The same command on server 2 gives the following output:

+ + ps -ef
+ grep ./test
+ grep -v grep
+ wc -l
run=2
+ echo 2
2

I need some help to find out why the first sever says 1 and the second server says 2. They are both HP-UX.

Thanks,
GBR

[Steven E. Protter]

Shalom,

All indications are that there is a second process running on server2.

However the basic methodology is flawed as ps -ef | grep provides inaccurate results and should never be used to write process kill lists.

UNIX95=1

More accurate process list methodology.

ps -a -o pid,sz,vsz,args -C $FILTER
# this format shows memory use but you get the idea

SEP

[Geoff Wild]

Well - on the first server, it is running the wc -l prior the grep -v

Are both servers on same OS release and patches?


Rgds...Geoff

[Sandman!]

Imho a better maybe unique name for your script might help. The name test could be part of another actively running process on the system or may have been passed as an argument. Picking a distinct name might help resolve the issue.

[Geoff Wild]

This works:

# cat test
#!/bin/sh
set -x
ps -ef | grep ${0} |grep -v grep > /tmp/test.out
run=$(cat /tmp/test.out|wc -l)
echo $run

Rgds....Geoff

[James R. Ferguson]

Hi:

I am in agreement with Sandman. Using the name "test" mimics the inbuilt 'test' command. Run this script in the background and then run yours:

# cat ./muddy
#!/usr/bin/sh
test -z $0
exit

...Your script will return "2".

Regards!

...JRF...

[Sandman!]

How about leveraging the XPG4 capabilities of ps(1) i.e.

# run=$(UNIX95= ps -C test -o comm= | wc -l)
# echo $run

[James R. Ferguson]

Hi (again):

Oh, H*ll. Disregard my post. I concocted a bogus case! However, naming a script 'test' is poor at best.

Regards!

...JRF...

[Bill Hassell]

Using ps and grep together is the worst, most unstable way there is to locate a process by name. grep cannot tell the difference between programs test, tester, 123test, and will also fail by finding a user ID called abctest or a group called qatest. And the reason you have to use grep -v is that grep will also look at the command line where some other program is using some parameters that test buried in the string.

So disregard all Unix beginner manuals that show the ps|grep combinations (and waste time looking at every process) and instead, use the 100% accurate features of ps. Did you know that you find an exact PID such as 123 (and not accidently find PID 1234 or 4123):

ps -fp 123

Or find all processes running as a particular user:

ps -fu billh

For you example, you add the XPG4 option -C by using the UNIX95 variable:

UNIX95=1 ps -fC test

This *always* works. Be sure to type this command on one line and do NOT export UNIX95. The above construct temporarily defines UNIX95 just for ps. To rewrite your script correctly, you must not use ${0} as your script's name. The reason is that you can start your script in many different ways:

./test
test
/usr/local/bin/test
../bin/test

and of course, $0 will be the complete string with all the (extra) directory junk. Instead, isolate your script's name like this and drop the -ef options:

#!/usr/bin/sh
MYNAME=${0##*/}
echo "$MYNAME run=$(UNIX95=1 ps -C $MYNAME | wc -l)"

[Dennis Handly]

You of course can use "ps -fp $$" to get the current process. And $PPID to get your parent.

>I need some help to find out why the first sever says 1 and the second server says 2.

Well, remove the "wc -l" so you can see what you are getting.

>Geoff: on the first server, it is running the wc -l prior the grep -v

I think that is a red herring. Pay no attention to the man behind the green curtain. :-)

[GBR]

Thanks everynone.

I found another thread that did this:

MYPROC=${0##*/}
MYPID=$(UNIX95= ps -C $MYPROC -o pid=)
COUNT=$(echo "$MYPID" | wc -w)

It works great.

GBR