If I define my cron scheduler via
crontab -e, the scheduler works correctly. However, putting the file in
/etc/cron.hourly/ doesn't work in my case.
run-parts --test /etc/cron.hourly output the script. Also, the script name is
my_sql_backup and doesn't have a file extension.
The script is
root:root with 777 permission.
cron.hourly scheduler seems to be working as this is the output of
grep CRON /var/log/syslog:
Mar 1 11:17:01 my-instance CRON: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Also, if I manually ran the command, the scheduler ran just like it should:
sudo bash -c "cd / && run-parts --report /etc/cron.hourly"
However, this seems to be not working actually. The script is back up MySQL database to Google Cloud Storage, but the storage isn't updated when I check it via Web Console.
Is there anything I'm missing here? Why does my scheduler script that was put in
/etc/cron.hourly/ not work?
Having added the
echo test > /tmp/foobar.tmp line to my cron script, I found that the tmp file is there. In fact I found my own tmp file issued by the script.
The content of the script is the following. So maybe the problem occured in running
# define environment variables here sudo sh -c "mysqldump -u$MYSQL_USER -p$MYSQL_PASS $MYSQL_DBNAME --single-transaction | gzip -9 > $MYSQL_TEMPPATH" >/dev/null 2>&1 gsutil cp $MYSQL_TEMPPATH gs://$GS_BUCKET_NAME/$MYSQL_S3_DESTPATH >/dev/null 2>&1
Again, the script worked fine if I manually ran it, so the environment variables are set to correct values...
I finally found that after getting the log file issued by
gsutil command, it has the following content:
AccessDeniedException: 403 Insufficient OAuth2 scope to perform this operation.
I still have to investigate why the access is denied if run in
/etc/cron.hourly/... But the problem was on
gcloud, not cron... Thank you for the support at the comments.