Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
*/30 * * * * /root/bin/check.sh
if ps ax | grep -v grep | grep $SERVICE > /dev/null
echo "$SERVICE service running, everything is fine"
echo "$SERVICE is not running, starting minecraft server"
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.
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.