Hey All,
Quick question...
I'm writing a short script to check if a continuous port is running on a server.
I'm using "ps -ef | grep -v grep | grep processName" and I was wondering if it was better/more reliable to just check the
return code from the command or if its better to pipe to 'wc -l' and check if it is '1' or not?
I was just curious if one method was more reliable then the other?
The server is "AIX 6"...
Thanks in Advance,
Matt
They both do the exact same thing, but the return code method is simpler and costs one less process. The simpler way tends to be the best.
However: You're putting yourself through a lot of needless pain here:
if pgrep processName >/dev/null
then
...
else
...
fi
You should find pgrep in most places.
Hey Corona, thanks for the reply!
Ok cool... I've never used "pgrep" before, thanks I'll give that a try.
Thanks Again,
Matt
also, pgrep directly prints pid's, so if you need them as output it can be used unfiltered.
Ugghhh, nevermind....
Looks like the UNIX server (which is probably older then myself, or pretty darn close) doesn't have the pgrep command.
It only has: grep, egrep, fgrep and zgrep...
ls -l /usr/bin | grep "grep"
-r-xr-xr-x 3 bin bin 34052 Jan 7 2011 egrep
-r-xr-xr-x 3 bin bin 34052 Jan 7 2011 fgrep
-r-xr-xr-x 3 bin bin 34052 Jan 7 2011 grep
lrwxrwxrwx 1 root system 27 May 12 2012 zgrep -> /usr/opt/freeware/bin/zgrep
Oh well, thanks anyways... I'll probably be able to get some use out of that on a slightly newer server. I guess I'll just go with the original idea.
Thanks Again,
Matt
What is it? uname -a It'd be useful to know where pgrep is absent... I thought it was somewhat universal.
Yea I thought the same thing...
It's a pretty ancient system that I "think" we plan on replacing soon... FINGERS CROSSED!
Running mostly dreaded UniData stuff.
#uname -a
AIX hostName 1 6 00C595524C00
No worries though I should be fine with the 'ps | grep' commands...
Thanks Again,
Matt
If the process or utility is coded to return its exit code, I recommend using it to verify whether it succeeded or not.
If you do not have pgrep, use grep:
if ps -ef | grep [p]rocessName
then
...
fi
Here is the reason why I enclosed the first character inside square brackets:
$ ps -eaf | grep PatrolAgent
yoda 29701 14851 0 16:12:47 pts/9 0:00 grep PatrolAgent
patrol 1641 1 80 Mar 14 ? 1961:08 PatrolAgent
This will help you to save a pipeline for grep -v grep
$ ps -eaf | grep [P]atrolAgent
patrol 1641 1 76 Mar 14 ? 1961:08 PatrolAgent
I was just curious if one method was more reliable then the other?
AFAIK, the two methods are exactly the same reliability. If grep finds a line, $? will be zero AND there will be output so wc -l result will be at least one. I would use the $? method, because one less step, unless there is some issue about the number of lines that grep might find.
It's fine to use grep -v grep | grep pattern
The other methods suggested (pgrep and [p]attern)are fine too. 
But I don't think they are "better". The other methods are (a little) shorter, so that's a small advantage. But one method is subject to failure if pgrep not present, the other admittedly clever method is not obvious to many users why it works, can be confusing to many users. I would normally use the simple way you presented.
hanson44, I don't have any concerns if you think that using grep -v grep is cleaner, not that much of a waste.
But I would like to remind you that the name grep comes from the ed command: g/re/p (global / regular expression / print)
So if using regular expression: [p]rocessName clearly eliminates the need for using grep -v grep and thus save a process, then I strongly believe we should use it.
By the way it is your privilege to waste processes if you want. So feel free...
Most ps-grep pipelines are underspecified (including all instances in this thread). Consider the following:
The pattern is evidently intended to match only a command name, but then why is it allowed to match any portion of a full listing? With such a promiscuous approach, usernames, command line arguments, and ps headers can trigger a false positive.
Even if the match is restricted to the command name, if the pattern isn't anchored at both ends, substring matches could cause false positives.
These have the added limitation of not being capable of searching for a grep command.
If I were going to use ps to portably test for the existence of a process whose command name is exactly cmdName, it would look something like this:
ps -eo comm= | grep -qFx cmdName
If portability isn't a concern, on a Linux system one could also use:
ps -C cmdName >/dev/null
It's not just about being concise; pgrep makes it simple to do the right thing. Its default behavior is to match against the command name only (args are excluded unless -f is provided). Further, a pgrep instance also excludes itself from the list of results, making it trivial to search for other instances of pgrep.
While it may not be available on the OP's system, pgrep has been widely available for about 5 years now on Solaris, HP-UX, Linux, OpenBSD, NetBSD, FreeBSD, OS X, and others.
Regards,
Alister
Well, I read what you said, and took a look at the man page, and I change my opinion. pgrep is "better". I just didn't realize pgrep had so many useful options. Thanks for correcting my wrong idea.
Wow!
Hey Guys, thanks for the replies!! Didn't think this would spark as much as it did, but I'm glad it did! LOTS of good info here...
Yea, I wish the system I'm running this on had pgrep, I checked out the manpage for it on "MY" own laptop (OpenSuSE 11.4) and it seems like
it would have been a better option if it were available on the AIX box... But oh well I'll just have to stay with the existing command. Thanks!
Yoda,
Yea I found out about using the [..] method a while back and it worked like a charm for MANY MANY other scripts I wrote, so I might try to
include that in my current script and remove the "grep -v grep".
Thanks EVERYBODY for all your replies, much appreciated!!
Thanks Again,
Matt