You did not specify how you added your cronjob. This makes a big difference: if you've used crontab -e
within your own account, scripts are run with your user (and thus the crontab entry has one field less -- the user to run it, as that is known). If you simply copied your above snippet to /etc/cron.d
, it would fail as you didn't specify a user (or rather as it finds no user named "bash"). So you should take the following steps:
- update your question with information concerning how you added the cron job
- check the system logs (
/var/log/syslog
; they could point to possible errors)
- add some debug output to your
Backup.sh
script to see whether it is started
The third point can be achieved in multiple ways:
- add a
>>/tmp/testlog.log
to the end of your crontab entry (to redirect output to a file you can investigate; additionally, a 2>&1
would include output from the error console)
- add some lines to your script itself, like e.g.
echo "Backup.sh started">/tmp/testlog.log
Moreover: As you intend your script to be run using bash
, you should not tell it to use /bin/sh
(which would make it use dash
on a default Ubuntu installation), but rather /bin/bash
. Then make it executable, and you can even omit the "bash" from your crontab entry.
Update:
According to your comment on my answer, you used crontab -e
to create the job, and according to your systems logs it is executed, but the definition is rather
*/5 * * * * bash /home/jonathan/Games/Minecraft/Server/Backup.sh &>/dev/null
This redirects all output to the biggest storage in your system, the "black hole": /dev/null
eats everything (but never returns anything). Redirecting STDOUT as well as STDERR this way robs you of any error report -- so you never know that they happened at all, let alone the details. For testing, you should omit the &>/dev/null
part completely. Even if it works, you should only suppress unnecessary output -- as otherwise you never know when something goes wrong. So better leave out the ampersand at least, so Cron can report any occurring errors.
Furthermore: Once the output is redirected (as in your case to /dev/null
), appending another redirect to the end will yield no results, as everything is already gone. So I have to adjust the above advice from "add ... to the end of your crontab entry" to "replace that in your crontab entry" ;)
see man 5 crontab
for details. Or, an all-in-one cron line:
*/5 * * * 1-4 (echo $(date) && echo $(free) && echo "") >> /tmp/memory.usage
Best Answer
Make the script executable by:
Note that, you need a shebang (i.e. indicate interpreter in the first line of the script), for
python2
:For
python3
:Open your cron table by
Add the following
cron
entry:Note that, if the script is not executable you can indicate the interpreter on the go:
For
python2
:For
python3
: