I'm running this simple script on my Raspberry Pi to auto update so I can forget about it. It also keeps a log that says whether the update was successful. The script is update.sh:
#!/bin/bash
echo "Update starts on: $(date)" >> /home/pi/update.log
if apt-get update && apt-get upgrade -y; then
echo "update successful $(date)" >> /home/pi/update.log
else
echo "Couldn't update $(date)" >> /home/pi/update.log
fi
I added this script to the root crontab by using sudo crontab -e and the cronjob is set to run every day at 6AM
0 6 * * * /home/pi/update.sh
I know that it works to some extent because running sudo ./update.sh in the shell manually runs the commands and leaves a "successful" entry in the log. On the other hand, when ran from the crontab, I always get the "couldn't update" entry. In case it matters, the "update.sh" script was created by the "pi" user and I never changed the permissions, except giving it execution permissions.
I read another question about the same problem and the guy solved it by putting a sudo in front of the command. He admits it's weird because it's already being executed by root, but says it works. I tried adding the sudo and verified it actually works now.
Does anyone know why this happens? Why does it need the sudo if it's already root?
Best Answer
Cron runs commands from a special shell, separate from the user or root shells. This shell does not have access to the same PATH variables as users. Therefore, when running a script as a cron job there are two options:
A. Specify the full path for every command in the script (I.e. full path to aptitude- cron doesn't know where to look to find "apt-get")
B. Little trick I use- when writing the cron job line, even in the ROOT crontab, append sudo before the script path. This will trick cron into running the script from a root shell instead of the cron shell, which will give it access to all root's PATH variables.