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.
When a user logs in his environment (variables including $HOME, $PATH, $TERM) are set for him and commands run by that user inherit that environment.
cron on the other hand does not actually "login" so it runs a minimal environment. The most common issue is that the PATH variable of a logged in user often has far more in it than the one cron runs for the same user.
Login as the user and run "env" to see the environment. Run "echo $PATH" to see what the PATH variable contains. Then run a simply cron job to output those two commands to a file and you'll see lots of differences.
Do NOT use $HOME in your cron directory specification - use the actual path to the user's $HOME (e.g. /home/username/log instead of $HOME/log).
cron itself does have a log in /var/log/cron usually. This won't show the output of the actual command but will show you whether cron tried to run the command. My guess is that it did.
To solve issues with a script not running properly in cron you typically just need to add full paths to commands OR explicitly set the PATH variable in the script so it includes the directories that contain the commands you want to use.
That is to say if your script was doing something like:
ps -ef |grep myprocess
You could run "which ps" and "which grep" to find out location of both of those commands. Typically they're both in /bin so you could modify your script to instead do:
/bin/ps -ef |/bin/grep myprocess
ps -ef |grep myprocess
The PATH=$PATH:/bin tells it to append /bin to whatever is already in the PATH variable. The above is a simple example - you can add other paths. For example say you needed things from /usr/local/bin and myuser's $HOME/scripts (where $HOME = /home/myuser) directory you could put in your script:
As noted above PATH is the most common issue but there could be others which is why it is important to know what the environment of the logged in user is and compare it to what the script will have when run as cron. One way around this is to simply run the script with su to the user with the "-" flag as that will setup the environment the same as it would be if the user was logged in (mostly - it won't set $TERM because it won't be running on a terminal). This can make your log output ugly but otherwise make your script run.