Cron using massive amounts of CPU
 

Hello,

I run a Minecraft server. It's just a Java application. I wrote a bash script that monitored the process and whenever it went down, it starts back up again. I have this set to run every 30 minutes in my crontab.

When I manually run the script, Java uses maybe 30% of my CPU.

When my script detects that the server is down via a cron instance, it uses upwards of 99%. What's going on?

Cron Entry:
*/30 * * * * /root/bin/check.sh

Script:
#!/bin/sh
SERVICE='java'

if ps ax | grep -v grep | grep $SERVICE > /dev/null
then
echo "$SERVICE service running, everything is fine"
else
echo "$SERVICE is not running, starting minecraft server"
startmc
fi

Startmc script:
cd /var/games/bukkit
./start

Start Script:
java -Xmx1042M -Xms1024M -jar craftbukkit.jar

You use things in the script (ps, grep) that you don't have full path of the command listed for. When you login you are invoking various profiles for the shell that set environmental variables including PATH. When you run a command in the background (e.g. via init script, udev, cron) it inherits a very minimal environment. Key variables are either not set or not as complete as they are after a login. The main one usually being PATH. You can type "echo $PATH" to see what this is set to. You can type "env" to see all the variables set. You could then add these to your script to output to files and see the difference the script outputs when run as udev as opposed to from command line.

The simplest thing is to put full paths of commands in. Alternatively when you have a lot of them you can simply set the PATH variable at the beginning of the script so it can find all the commands you're using later. (You do still need to do the full path to bash at the #! line because that tells the script to run in bash shell.)

Also the "echo" command is both a shell built in and a binary that can be called. Sometimes you get odd results when you're using one and think you're using the other.

The ps cmd line is read left to right, so reverse
to eliminate grep match

It should work either way though the doing it the first way would make the second grep have to read through far more entries than it would the second way so I agree with your suggestion. I doubt, however, that this is the cause of the long run time the OP described.

Yeah, just a minor thing, it just cleans up the output if you need to parse it.
The timing thing I have no idea :)

Adding to this you also need to check what all other processes are utilizing cpu processing.