Hi all,
I am having an issue with my cron jobs not running, so my /etc/crontab looks like this:
59 23 * * * root /srv/script
This hasn’t run for the last three days, the script does a SQL backup, so what I done was created a cron job like the below:
00 09 * * * env > /tmp/env.output
But this file is never created, I have run the command in terminal to confirm that is OK, I’ve also checked that the cron service is running.
Is there a log file I can review to see why this failed?
Thanks!
Does your script have shell properly defined by using #!/bin/sh at the start and are you sure the script has executable bit set?
On 2014-09-08 12:16, poobear85 wrote:
> Is there a log file I can review to see why this failed?
/var/log/messages
And mail.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Hi,
Yes it does, I used the below command to set the executable:
sudo chmod +x scriptname
Thanks,
Also to note if I run the script this works as expected.
The script has run the commands, so the schedule is working but it hasn’t created the file expected, would anyone be able to help?
Sep 8 11:50:01 localhost /USR/SBIN/CRON[6594]: (root) CMD (/srv/Backups/MySQL/SQLBackup)
Sep 8 11:50:01 localhost sudo: root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/usr/bin/touch backupfile20140908.sql
Sep 8 11:50:01 localhost sudo: root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/bin/chmod 777 backupfile20140908.sql
Sep 8 11:50:01 localhost sudo: root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/bin/chown wwwrun backupfile20140908.sql
Script is below:
#!/bin/sh
sudo touch backupfile`date +%Y%m%d`.sql
sudo chmod 777 backupfile`date +%Y%m%d`.sql
sudo chown wwwrun backupfile`date +%Y%m%d`.sql
mysqldump --hex-blob --skip-comments --socket /tmp/mysql.sock -h 127.0.0.1 -u USERNAME -PASSWORD DATABASE > backupfile`date +%Y%m%d`.sql
Use absolute path and capture stderr too in env.out
00 09 * * * /usr/bin/env > /tmp/env.output 2>&1
Most likely the commands/executable in your script needs absolute path too, or it might have something to do with the sudo too :).
Try adding an appropriate “cd” command near the beginning. The RPM instruction (Read the Programmer’s Mind) is not working.
Why are you using “sudo”?
The script is run as root anyway, no?
And you should “cd” to the directory whery you want to create the file, as someone else mentioned while I wrote this… 
The file probably got created somewhere where you did not expect it…
Just keep in mind you need to check if the directory exist before you cd from a script and also exit immediately if the directory does not exist. Why? just a simple cd will bring you to “$HOME” in this case /root. It is not always intended/accepted specially if it involve rm ;).
With an existing directory it is fine. (or variable is not empty)
jetchisel@Localhost:~> mydir=/tmp
jetchisel@Localhost:~> cd "$mydir"
jetchisel@Localhost:/tmp>
Without an existing directory it is not. (or variable is empty)
jetchisel@Localhost:/tmp> mydir=
jetchisel@Localhost:/tmp> cd "$mydir"
jetchisel@Localhost:~>
Just imagine running an rm after the cd, then the next step would be restoring your “$HOME” directory from backup.
The most common approach is.
cd mydir || exit
some code here
more code here
some more code here
That should exit the script if mydir does not exist and will not continue to run code after it.
Some folks test the directory first and do an if clause to cd into mydir.
if mydir ]]; then cd mydir && 'run your other code here'; fi
or
if mydir ]]; then
cd mydir
some code here
more code here
some more code here
fi
Use a subshell put the cd and other commands inside the () if you don’t want your directory to be change after the script is done.
if mydir ]]; then
(
cd mydir
some code here
more code here
some more code here
)
fi
Note the is bashism you need or test for /bin/sh shebang.
Or just create it if it doesn’t exists, probably with “mkdir -p /path/to/directory”.
No need to exit immediately in this case.
If you don’t check for the existence and try to cd to a non-existing directory, the cd will fail and your script will immediately abort, anyway.
Why? just a simple cd will bring you to “$HOME” in this case /root.
True, but if you run something like “cd /path/to/directory” this can not happen, as you do not just call cd. So I don’t see the point in mentioning this here.
You’re thinking of using a variable that might be empty, right?
Well, if you use a variable, then do not forget to set it to the directory you want to cd to, yes.
In this case even with an empty variable nothing bad will happen though, just the files will end up in /root, which might even be intended.
And run
help test
if you are using since does not need the -n for testing a non empty variable, if you are testing for a variable and a plain directory.
Or just cd to a directory you are sure that exists, like /root e.g.
No reason to overcomplicate everything…
Between you and me, i don’t think i need to explain everything like i always did here in the forum but i always assume the OP needs some explanation even if it means complicated to others
Thanks all, cron was working. I assumed the file creation was happening in the location of the script, but it was happening in ‘root’ user profile. Adding the cd command in the script has fixed the issue, sorry to have troubled so many people!
Well, but at the moment the question is why the script/cronjob doesn’t create the files. No need for a lecture about how to check whether a directory exists and only execute the code if it does at this point, IMHO.
Right now, it’s better to just cd to an existing directory, and see whether the files are there afterwards.
By doing it in a more complicated way like you describe, you only increase the chances that some other errors creep in that prevent the script from working as intended.
Makes it even more complicated to find out why it doesn’t work then.
But that’s just my opinion.
On 2014-09-08 13:06, poobear85 wrote:
>
> robin_listas;2663426 Wrote:
>> On 2014-09-08 12:16, poobear85 wrote:
>>
>>> Is there a log file I can review to see why this failed?
>>
>> /var/log/messages
>>
>> And mail.
> The script has run the commands, so the schedule is working but it
> hasn’t created the file expected, would anyone be able to help?
Then read your system mail! :-))
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-09-08 13:06, poobear85 wrote:
> Script is below:
>
>
> Code:
> --------------------
>
> #!/bin/sh
>
>
> sudo touch backupfiledate +%Y%m%d.sql
>
> --------------------
As your line was:
59 23 * * * root /srv/script
it is already running as root, so “sudo” is superfluous.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-09-08 12:16, poobear85 wrote:
>
> Hi all,
>
> I am having an issue with my cron jobs not running, so my /etc/crontab
> looks like this:
…
> This hasn’t run for the last three days, the script does a SQL backup,
> so what I done was created a cron job like the below:
>
> 00 09 * * * env > /tmp/env.output
If that line is in “/etc/crontab”, it is trying to run as user “env” the
file “/tmp/env.output”, which is probably not what you want.
Unless the above is in a user crontab - but you have not said so.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)