Custom cron woes


#1

I have a custom cron job set up, well almost.

I currently have (in a custom role):

- name: Setup cron to trigger B2 backups
  cron:
    name: "{{ item.key }} site cron"
    hour: "{{ item.value.cron.hour | default('*') }}"
    minute: "{{ item.value.cron.minute | default('*') }}"
    user: "{{ web_user }}"
    job: "cd {{ www_root }}/{{ item.key }}/{{ item.value.current_path | default('current') }}/scripts && chmod +x {{ item.value.cron.filename }} && ./{{ item.value.cron.filename }}"
    cron_file: "custom-{{ item.key | replace('.', '_') }}"
  with_dict: "{{ wordpress_sites }}"
  when: item.value.cron | default(false)

Then, in wordpress_sites.yml, I have:

cron:
  filename: "b2-backup.sh" # this is the file that the backup cron will be run against
  hour: "*" # runs every hour.
  minute: "*/5" # runs every 5 minutes for testing

Now if I check var/log/syslog, I can see the cron seems to be running as anticipated:

Mar 16 19:50:01 trellis-backup-test CRON[15071]: (web) CMD (cd /srv/www/example.com/current/scripts && chmod +x b2-backup.sh && ./b2-backup.sh)

However, the result (a backup to Backblaze B2) isn’t happening and I don’t really know how to diagnose what’s failing or if the cron job just isn’t valid. If I SSH into the server as the web user, I can execute the exact command as shown in syslog i.e. cd /srv/www/example.com/current/scripts && chmod +x b2-backup.sh && ./b2-backup.sh and it works perfectly and the backups turn up in the B2 bucket as expected.

Any ideas?


Permissions when adding a custom cron job on deploy (permission denied)
#2

Cron environments are pretty limited, so depending on what you’re doing in your script, it’s possible that something is not available when cron runs the script.

For instance, I can’t run aws (AWS CLI) directly in my backup script with cron — I had to pass the full path to the binary (/usr/local/bin/aws).


#3

Interesting. Thanks for the heads up, I didn’t know that.

I’ll give that a go and see if I can make any progress as it’s so close!


#4

The discourse answers and Roots team are totally on point today :wink: That’s two for two in a day!

That worked perfectly; I changed the instances of accessing the B2 CLI using the normal method and instead gave the absolute path to the binary.

So:

b2 upload_file $B2_BUCKET_NAME $SQL_FILE.gz db/$SQL_FILE.gz

becomes:

/usr/local/bin/b2 upload_file $B2_BUCKET_NAME $SQL_FILE.gz db/$SQL_FILE.gz

Bit of tiding up to do but I’ll post up the role and script I’ve put together in case it’s of use to anybody.