Cron job not executing

Tags:

Answer: 1

14 hours ago

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?

Added by: Dolly Stanton

Answer: 2

32 hours ago

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:

  1. update your question with information concerning how you added the cron job
  2. check the system logs (/var/log/syslog; they could point to possible errors)
  3. 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" ;)

Popular Search

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 1 2 3 4 5 6 7 8 9