I was making a cron job to save my Minecraft world from my ram every 5 minutes.
I tested the script and it seems to be working.
This is what the script looks like:
#!/bin/sh
VOLATILE="/home/jonathan/Games/Minecraft/Server/world/"
PERMANENT="/home/jonathan/Games/Minecraft/Server/world_storage/"
rsync -r -t -v "$VOLATILE" "$PERMANENT"
So then I went to add a cron job to run the script every 5 minutes, and it doesn't seem to be running it.
This is the script I used:
*/5 * * * * bash /home/jonathan/Games/Minecraft/Server/Backup.sh
Can anyone help me please?
Best Answer
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:/var/log/syslog
; they could point to possible errors)Backup.sh
script to see whether it is startedThe third point can be achieved in multiple ways:
>>/tmp/testlog.log
to the end of your crontab entry (to redirect output to a file you can investigate; additionally, a2>&1
would include output from the error console)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 usedash
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 ratherThis 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" ;)