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.
In the root crontab you don't need "sudo" to run as root. The root crontab itself runs as root. Also "sudo" is interactive (requires user to input their password) so would not run in the background anyway. To switch users you use "su" rather than "sudo".
Restated: Become root first THEN do your "crontab -e" to add the job to your root's crontab file.
Not sure why it wouldn't work unless it is finding the previous invocation already running and you have it testing for that. It would depend a lot on what is in the script itself. (You really don't want multiple copies of the same shell script running at the same time - they contend for the same resources and will eat up your CPU).
I would suggest however that instead of doing:
sh /etc/ppp/ip-up.d/dyndns_update.sh >> /home/USER/Desktop/dyndns.root
The first change gets rid of the extraneous shell with cron itself which may confuse things a bit. It also redirects standard error (stderr) to standard out (stdout). As you had it only stdout would go to the file dyndns.root.
The second change insures your commands within the script are executed with /bin/sh. (This is called the interpreter and is special syntax.) This way even if someone running another shell (ksh, csh, zsh) runs the script it will behave the same way every time because it runs as sh.
Finally remember that even if your script is successful from command line it may fail in cron. This is because at command line the script inherits the user's environment ($PATH, $HOME, $DISPLAY, etc...) but cron runs a minimal environment not a user's environment. Therefore you must insure the script (dyndns_update.sh) contains all the environment variables you'll need (especially $PATH) so it can find what its looking for when it runs.
Last edited by MensaWater; 06-16-2006 at 12:17 PM.
# the details below were edited to make it safe to post it here
# the version on my PC has the right details
if [ -f /root/ipcheck.dat ]; then
ipcheck -r checkip.dyndns.org:8245 $USERNAME $PASSWORD $HOSTNAME
ipcheck --makedat -r checkip.dyndns.org:8245 $USERNAME $PASSWORD $HOSTNAME
if you don't mind, could you please explain the 2>&1 in more detail? or at least tell me what it's called so i could look it up on google. i know you mentioned stderr and stdout but is there a name for them together in this context?
It appear from the way your post looks that you have a space before what you call the shebang line (actually known as the interpreter line). The special syntax requires the # to be the first position on the line so if there is actually a space before it you should remove it.
(# in any other location is a "comment" identifier meaning do NOT process what follows the #).
ANSWER TO PATH QUESTION:
Nice trick on figuring out which PATH cron uses there. You are only calling one external command in your script which is ipcheck. (Not counting the interpreter line which has full path to sh in it already.)
Since you see cron uses /bin and /usr/bin to find files the answer to whether you need to define PATH depends on whether the external commands you're calling reside in the PATH you already have. Type "which ipcheck". If it is in /bin or /usr/bin then you don't need to define it (though I likely would anyway). You don't actually have to have the PATH statement though. If you wer calling multiple external commands you might want the PATH statement just to avoid a lot of typing. An alternate way to do it is simply to use the fully qualified path name. Finally you can simply create a variable for the fully qualified path name of the executable which is what I usually do in cron and init scripts.
Example - assume the command ipchceck is in the directory /usr/local/ipchceck/bin:
Use fully qualified path name each line you want to use ipcheck:
[CODE]if [ -f /root/ipcheck.dat ]; then
/usr/local/ipcheck/bin/ipcheck -r checkip.dyndns.org:8245 $USERNAME $PASSWORD $HOSTNAME
/usr/local/ipcheck/bin/ipcheck --makedat -r checkip.dyndns.org:8245 $USERNAME $PASSWORD $HOSTNAME
Define a variable for the executable:
if [ -f /root/ipcheck.dat ]; then
$IPCHECK -r checkip.dyndns.org:8245 $USERNAME $PASSWORD $HOSTNAME
$IPCHECK --makedat -r checkip.dyndns.org:8245 $USERNAME $PASSWORD $HOSTNAME
ANSWER TO DISPLAY QUESTION
No. I used DISPLAY only as an example of common variables. In a recent thread I did see where a user found a use for having cron have that variable but in general cron stuff is backgrounded so wouldn't need DISPLAY.
ANSWER TO 2>&1
Actually I had recently given an explanation of redirection and the tee command in another thread. Hopefully it will explain the 2>&1 to you in more detail. Have a look and if not let me know:
Last edited by MensaWater; 06-17-2006 at 10:40 AM.