using 'ps' in a kill script

[Mike Rightmire]

I am attempting to write a script which searches the running processes for specific process names, and then kills them if they are older than a certain time, which needs to be variable.

I have searched the site and come up with many answers already for the script I am trying to write, and I am going to try and use 'ps -ef | grep [variable]' to find the processes. The question is this ...

How do I get PS to display the etime (elapsed time) I have read about in the manual, or in lieu of that, can I get the output from the ps command to list the date in a specified format (I.E. by total minutes.)

If I cannot get the etime to display or the date to display in minutes (or whatever) can I at least get it to always display in the HHMMSS format, or will I have to have a line in the script to determine if the $time variable (lets call it) that I grab from the 'ps' output is numeric or text (I.E. 12:37:52 as opposed to Jan 10.)

Thanks for all the help and any general suggestions for a script of this type would be great too!
Mike

[Maureen Gunkel · Accepted solution]

Mike,
You probably would want to use the 'UNIX95' variable for ps. Here is a copy of my alias:
alias psfe="UNIX95= ps -ef -o user,pid,ppid,cpu,etime | more"
and here is a sample of that output:
oracle 14080 1 0 1-06:13:30
ext2wxh 15553 15545 0 05:57:09
oracle 13812 1 0 1-06:13:38
oracle 14641 1 0 1-06:13:14

You'll notice that anything with an elapsed time of more than 24 hours is prefaced with '1-', so you'll be able to grep or awk for that.
If you need further assistance, I'd be happy to help out - just reply again!
Maureen

[James R. Ferguson]

Mike:

Probably the most helpful flavor of 'ps' is the XPG4 behavior armed with 'UNIX95'. In part, this changes the TIME column format from mmmm:ss to [dd-]hh:mm:ss. The STIME (start time) column is still going to display an alphanumeric date once the STIME (ago) exceeds 24-hours.

Compare, for example:

# ps -ef
# UNIX95= ; ps -ef

See Bill Hassell's comments in this thread (if you haven't already so noted them):

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0xaaf75f260cafd4118fef0090279cd0f9,00.html

...JRF...

[Mike Rightmire]

Thanks for the fantastic answeres. The UNIX95 info was exactly what I needed. NOW, unfortunately, I have come up with a dozen other questions regarding getting this script written. I will narrow it down to the two most pressing ones ...

1. The client will type the script in at the command prompt, with a bunch of parameters. I.E. script A 1 B 2. Is there a simply way to verify that the first and third params were letters, and the second and fourth params were numbers.

2. I cannot seem to get a trap to work. I have a number of 'if'; statements which if true (or false, depending) end the script with an exit code. But when I use the trap command I.E...

#
trap "echo you goofed it up" 1

if test $# -lt 1
then
exit 1
fi
#

... which (as I understood it) should cause the trap to execute if the user does not enter any parameters and the if statement ends the script with an exit code of 1

However mine does not. It just exits and the trap does not run. If I modify the trap command with a '0' on the end (indicating it should "trap" from an exit code of 0, which is the exit code for a successfully completed script) it works fine.

What am I doing wrong???

Thanks again!

[Mike Rightmire]

Hmmm...also, question number 3...is there a way to get the script to use the trap statement, or go to a different segment of the script if an error in the script ocurrs without control...

I.E. I try to divide a variable which was supposed to be a number, but it was a letter and the script stops with a "bad number" error message. Is there a way to get the script to run a trap or continue to a different part of the script is an error of this type happens?

Thanks again!
Mike

[James R. Ferguson]

Hi Mike:

1. One way to validate that a variable is made up of only numbers or only letters is to use 'expr' to compare a variable to a regular expression for the number of characters it contains:

# if [ `expr $X : '[0-9]*'` -eq `expr $X : '.*'` ]
# then
# echo "is numeric"
# fi

# if [ `expr $X : '[a-zA-Z]*'` -eq `expr $X : '.*'` ]
# then
# echo "is alphabetic"
# fi


2/3. A 'trap' catches an interrupt and takes an action (or maybe none). In the absence of an exit or return statement, the transfer of control is back to the point of the interrupt. The numbers you associate with a trap statement represent the signal number. Signal zero (0) is an exit. Signal number-3 (QUIT) is the CTRL_C sequence.

For instance, to remove a temporary file /tmp/$$ whenever your shell script exits, you could code:

# trap (rm /tmp/$$; exit 0) 1 2 3 15

Thus, a HUP, INT, QUIT, or TERM signal will interrupt the script, remove the file whose name is the PID value of the script from the /tmp directory; and exit with a return value of zero (0).

Do not confuse the numbers used in trap statements with exit codes. The trap's numbers are signal numbers (see: 'man 2 signal' and 'man kill'). Exit codes (return values) are values propagated to an outer block denoting success (0), failure (1) or warning (2) by convention.

...JRF...

[Bruce Regittko_1]

Hi,

James' explanation is right on the money. Instead of

trap "echo you goofed it up" 1

try

trap "echo you goofed it up" EXIT

or

trap "echo you goofed it up" 0

--Bruce

[Mike Rightmire]

Hey folks,

A couple more quick comments. Note in the script that if the -p parameter is used (changing the item 'grepped' for from the script default of abc......AB to whatever was entered as an argument to the -p paramete) this AUTOMATICALLY causes the script to use interactive mode which writes all the processes to be killed to a file, lists the contents of the file for approval, and then uses the listing in the file for the kill process assuming approval is given.

This is so that if the processes to be killed is changed from the std process you MUST see the list of processes and approve them before killing them.

Also, I did a lot of touch statements and then iether over-wrote the file or removed it. This was because HP-UX 10.20 was giving me errors when it attempted to remove a file which was not there. The trap statement removes the killoaspids.tmp file upon exit, but errors if it is not there.

For safety sake I always have the script create the file, then whether it uses it or not, kills the file upon exit. I did the same with the log file so that there could be no errors when it attempts to overwrite the file (in the beginning of the script) with the date information, and then it continues to append it throughout the script.

I chose to use a separate line for all logfile writing (instead of using the 'tee' command, as this script may end up being ru nwith all inout and output going to the logfile, in which case the internal log statements would have to be removed. Having them as separate lines just makes the rmoval easier if necessary.

Thanks!!
Mike

[James R. Ferguson]

Hi Mike:

You can easily eliminate the file touches and issue the remove in your traps without worrying about non-existent files by doing:

# rm -f filename

The '-f' forces (so use with care!) the remove without prompting for confirmation, regardless of the permissions of the file. It also suppresses diagnostic messages regarding nonexistent operands.

Regards!

...JRF...