sh script making CPU very high ..

[someone_4]

Hey everyone,
when I do a top on my mailserver
I get:
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
0 ? 27242 root 241 20 556K 216K run 10:44 79.05 78.91 sh
0 ? 9594 root 241 20 556K 216K run 99:29 56.23 56.13 sh
1 ? 13247 root 241 20 556K 216K run 217:53 52.21 52.12 sh

and when I grep for the PIDs I see a sh procces script.
# ps -ef|grep 27242
root 592 29852 1 16:33:59 pts/ta 0:00 grep 27242
root 27242 1 248 16:18:04 ? 10:58 sh -c echo '*****'; hostname; e
cho '*****'; bdf -l | grep -v
# ps -ef|grep 9594
root 9594 1 224 14:44:02 ? 99:53 sh -c echo '*****'; hostname; e
cho '*****'; bdf -l | grep -v
# ps -ef|grep 13247
root 639 29852 0 16:34:15 pts/ta 0:00 grep 13247
root 13247 1 255 12:37:56 ? 218:18 sh -c echo '*****'; hostname;
echo '*****'; bdf -l | grep -v

why would theese sh commands kill my CPU? and how can I fix this?

Richard

[Sridhar Bhaskarla]

Richard,

Unless we know what's exactly in there, we can't fix it. If you are not running these scripts, then kill them and check what exactly are they doing. People like me will definitely make the systems to suffer with bad scripting. For ex., Running five 'finds' simultaneously in a script will definitely heat up the system.

Most probably these could be cron jobs. Verify /var/adm/cron/log file to see if there is anything that is getting started during this time. Check the cronjobs and go through the scripts.

Multiple bdf-s on a system with NFS problems can be lethal.

-Sri

[A. Clay Stephenson]

Hi Richard:



The ps -ef is being truncated and I suspect that your real problem is that part we can't see. You need to find this command within a script / cronjob and post that.

[someone_4]

well its not in cron. I killed two of the jobs and my cpu is fine now. Is there a way I can find thoose jobs burried somewhere?

[A. Clay Stephenson · Accepted solution]

In that case, somebody has a script that they run. You could write a script which uses find to in turn grep a file for a pattern.

As a very simple first cut:
find . -type f | while read X
do
grep -q '*****' ${X}
STAT=$?
if [ ${STAT} -eq 0 ]
then
echo "File ${X}:"
grep -q '*****' $X
fi
done

This will look for all files with '*****' in them. You might want to replace that with an arg you pass in. Do not run this from / but rather from places you might expect to admin scripts; e.g /home/root /utils

Clay

[A. Clay Stephenson]

Oops Richard, take out the -q from the 2nd grep; you might want to see some output rather than just set an exit status as in the first grep.

[Bill Hassell]

Actually, the bdf command is probably the one that is killing your system. With more than a few mountpoints, bdf will spend a lot of time summarizing the occupied and free space, and will be severely slowed by huge changes to the contents of filesystem (adding or deleting lots of files).

If these scripts are looping, or constantly being re-run, then a large server with dozens of mountpoints will indeed be crippled. The first protion of the shell command looks like it might be trying to capture data from bdf, perhaps monitoring disk space. Look in cron...someone may have put a diskspace alarm script there.

As a note: ps has a number of very useful options:

ps -fp 1234 .. which finds just process 1234

(grep is non-discrimatory so ps -ef|grep usually finds things you don't want)

UNIX95= ps -fp 1234 -o pid,ruser,args

The UNIX95= flag changes ps behavior to allow the use of -o options. By reducing the default values with just pid,ruser,args you will see as much of the command line as possible.