LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (http://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   crontab job not executing.... (http://www.linuxquestions.org/questions/linux-newbie-8/crontab-job-not-executing-751564/)

mia_tech 08-31-2009 03:12 PM

crontab job not executing....
 
guys, I scheduled a job to backup my system in crontab and I'm using "dump" to do the backup, but for some reason the job is not starting. Here's the line in crontab

Code:

30 4 30 * * * root dump -0aj -f /mnt/storage/backup/linuxfull.bak /

any help appreciated

repo 08-31-2009 03:16 PM

Does it work from the command prompt?
any error messages?
Try to use the whole path to the command.
eq
/sbin/dump

mia_tech 08-31-2009 03:22 PM

Quote:

Originally Posted by repo (Post 3664348)
Does it work from the command prompt?
any error messages?
Try to use the whole path to the command.
eq
/sbin/dump

yes it works fro the shell... same exact command. I'll try that next, however, notice that I'm running this command as root, and I have ran it as root from the command line, so I think that the path is not an issue here

colucix 08-31-2009 03:22 PM

1. Check /var/log/cron for some useful message.
2. Check the standard output and the standard errors from the cron job (if any). Since you didn't redirect them to a file, most likely they have been sent by e-mail: check them from a terminal using the mail command.
3. If this is a user's crontab (root included) you don't have to put the username in the cron entry, that is remove "root" from the line you posted above.
4. Use full path for every command run in crontab. Check it using which dump and add it to the entry. This is because cron has a very limited environment - different from that set-up at user's login - and PATH is limited to /bin:/usr/bin.
5. Please, post any relevant result from points 1 to 4 above.

repo 08-31-2009 03:24 PM

cron has its own path, it is not the default path.
A good rule is to use the complete path to all commands and files

catkin 08-31-2009 03:27 PM

The usual "gotchas" are 1) that the environment provided by cron is not the same as the login environment, especially not having the usual $PATH is a problem and 2) any output from the script to stderr or stdout (that would normally go to the terminal) have nowhere to go and cron stops the job.

You can test whether 1) is the problem by changing the first line of the script to
Code:

#!/bin/bash -l
That's a letter l and tells bash to run the login process thus setting up the "usual" environment.

Solving 2) is a matter of redirecting any output to a file (maybe /dev/null) using something like > <some file> and 2>&1 (which directs stderr to the same place as stdout).

mia_tech 08-31-2009 03:42 PM

Quote:

Originally Posted by colucix (Post 3664359)
1. Check /var/log/cron for some useful message.
2. Check the standard output and the standard errors from the cron job (if any). Since you didn't redirect them to a file, most likely they have been sent by e-mail: check them from a terminal using the mail command.
3. If this is a user's crontab (root included) you don't have to put the username in the cron entry, that is remove "root" from the line you posted above.
4. Use full path for every command run in crontab. Check it using which dump and add it to the entry. This is because cron has a very limited environment - different from that set-up at user's login - and PATH is limited to /bin:/usr/bin.
5. Please, post any relevant result from points 1 to 4 above.

This is the root crontab file. I originally didn't especify the root in the file, but because it didn't run, I thought it might have been the absence of root, so I added it...

ok, I'll remove root and add /sbin/dump, and no, I have not checked mail or cron logs... I'll do that next. Should have been the first thing, but slipped my mind


All times are GMT -5. The time now is 05:13 PM.