Summary: manipulation of time values in shell script

From: Edwin R Wolfe Jr. <ewolfe_at_umich.edu>
Date: Mon, 11 Sep 2000 11:56:59 -0400 (EDT)

Thanks to the following for their replies:

Allan E Johannesen
Ashley Frost
Phil Farrell
Jim Belonis
Ian Mortimer
Bevan Broun
Graham Allan

I received a couple of sh scripts (one very complex), a ksh script, a Perl
script, and some suggestions. One was to just look for netscapes taking
over 50% cpu usage -- but that won't work as I often see several netscapes
individually taking under 50% but totalling 99%. The Perl script looked
promising, but we don't seem to have Perl installed on all of our
machines. One sh script was just about what we wanted: it used a table of
specifically named processes that submitter has seen to "runaway" along
with time limits for each. We haven't noticed the others in a runaway
state, so I "watered down" that script and came up with this a script that
accepts two parameters (procname and timelimit from 1 to 59 minutes) to
kill whatever one wants.

In thinking more about how to handle the 3 possible time format strings
output by ps it occured to me that, if there is no ".", the process has
already used an accumulated hour or more and it would be reasonable to
clobber it. Also, in comparing the mm:ss.dec parameter against a limit,
awk seems to use the mm and ignore the rest. Since there really is no
need to parse seconds and tenths of seconds the command reduced to:

PIDS=`/bin/ps -e -o pid,cputime,command | \
    grep $PROC | grep -v grep | grep -v $0 | \
    awk -v qq=$LIMIT \
       '{ if ($2 !~ /\./) print $1
          else if ($2+0 > qq+0) print $1 }'`
          
for xx in $PIDS
   do
   kill -9 $xx
   done

A caution: invocation with injudicious process name and time limit, such
as:

prockill : 0

will clobber a number of system processes such as /usr/bin/X11/X.

^^^^^^^^^^^^^^^^^

original message:

We often, using ps, find runaway (if that's the right term) netscape
processes. By runaway, I mean the user is either not logged in (the
easiest case to detect) or there are several netscape processes but some
no longer have onscreen windows (detected by killing the oldest and
noting that nothing happens on the screen). These seem to appear after
netscape crashes, but I can't reliably force the condition.

The ps output shows either a single process that uses 99% of cpu time, or
several of them using equal amounts of time that add up to 99%. The
<cputime> field of ps often shows large values: hours, even days.
These two clues seem to be the only way these can be detected. I've
tried looking at the status field, but that doesn't seem to distinguish
runaways from actives.

I'd like to write a shell script to be run by crontab every so often
to find these rogues and clobber them. I have seen the %cpu values
during normal execution exceed the values in the case of multiple
runaways, so it looks like using some cutoff value against the %cpu field
would not be quite the right thing to do. So, my thought is to use the
<cputime> field. I got this far:

PID=`/bin/ps -e -o pid,cputime,command | awk -v pp=$PROC -v qq=$LIMIT \
        '{ if (($3 ~ pp) && ($2 > qq)) print $1 }'`

with the intent to run a for loop to kill the collected pid's,
but the comparison of cputimes is wrong and I can't seem to find how to do
it. I notice that the cputime field varies in output:

0:00.49
6:47:52
2-3:16:08

Is there a supplied function that will take these time strings and do the
comparison, or must I write my own? If I write my own, how do I get awk
to use it -- or is there an easier way to record the pids with cputimes
exceeding a limit for use in a for loop?

Is there a reliable way to force a "runaway" netscape to help in the
debugging?

Is there perhaps an easier way to detect and kill these runaways, such as
a utility to detect whether or not a netscape window or icon is still
onscreen? (checking the tty field of ps doesn't help - it's often a <??>).

Or: heh, heh: or does anyone have such a script they'd be willing to
share?
Received on Mon Sep 11 2000 - 15:58:04 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:41 NZDT