Crontab Not Running

up vote

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

#!/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/

I know that it works to some extent because running sudo ./ 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 "" 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?

linux bash shell cron raspberry-pi


down vote






possible duplicate of Why does this script fail when run from cron, but works when run manually? –  Nifle Jan 30 at 18:15

I read that post and it gave a practical solution, but I don't think it gave an actual answer, not that I understood anyway. I rephrased the question to reflect that. –  freejuices Jan 30 at 18:27

The environment for sudo and pure root are not necessarily the same. try typing env as root and then sudo env and compare the results. –  Nifle Jan 30 at 18:31

It's like Windows UAC logged in as Administrator. Although you're logged in as the admin you are still just a normal user. To run a system function you have to "ask" for an admin token that gives you the ability to perform the task. This is the same for Linux (where, I believe, the idea originated) as it prevents the user accidentally doing something daft that could potentially ruin a system. –  Big Chris Jan 30 at 18:57

Does the failing apt-get command report any errors? Since you're not redirecting its output, it will be sent as mail to root. –  Barmar Jan 30 at 19:10

up vote

This is because the cron is running as your unprivileged user, and the apt-get commands require root (aka administration) elevation privileges to run.

An alternative is to run this command under the root user's crontab:

sudo -i <type user password> crontab -e

The first command elevates your entire shell to root and will also - crucially - give you access to root's environment, rather than just a single command as your user with elevated privileges.

The second command will edit the root crontab, not your own.


down vote

add a comment