cron.d jobs not working despite correct syntax

[borez]

Describe the bug
My cron.d scripts don't seem to work after migrating to 2.x. Am now running 3.0.20 and didn't realise the crontab wasn't running.

Created a weekly cron script to copy Unifi Network backup databases to the 3.5" HDD. This was the same script used for 1.x firmware, which worked with no issue.

25-add-cron-jobs.sh is updated to the latest version and runs without any issue (the /data/cronjobs files gets copied to /etc/cron.d). However, running crontab -l shows no crontab for root.

I realise most of Unifi's own cron scripts have a "root" appended in front. However, adding the "root" user didn't help either.

0 22 * * 1 cp -r /data/unifi/data/backup/autobackup/. /volume1/share/backup/UDMBackup/

[HateBaozi]

try this
0 22 * * 1 root /bin/cp -r /data/unifi/data/backup/autobackup/. /volume1/share/backup/UDMBackup/

[borez]

try this 0 22 * * 1 root /bin/cp -r /data/unifi/data/backup/autobackup/. /volume1/share/backup/UDMBackup/

Thanks for this but this didn't work either.

[GentleHoneyLover]

Had the same problem. Adding "root /bin/" before the cron command solved it for me.

[borez]

Had the same problem. Adding "root /bin/" before the cron command solved it for me.

Thanks, I couldn't get it to work. Do you mean by:

root /bin/ 0 22 * * 1 cp -r /data/unifi/data/backup/autobackup/. /volume1/share/backup/UDMBackup/

[GentleHoneyLover]

@borez, below is the example of my files:

/data/on_boot.d/25-add-cron-jobs.sh

#!/bin/bash
# Get DataDir location
DATA_DIR="/data"
case "$(ubnt-device-info firmware || true)" in
1*)
    DATA_DIR="/mnt/data"
    ;;
2*)
    DATA_DIR="/data"
    ;;
3*)
    DATA_DIR="/data"
    ;;
*)
    echo "ERROR: No persistent storage found." 1>&2
    exit 1
    ;;
esac
## Store crontab files in ${DATA_DIR}/cronjobs/ (you will need to create this folder).
## This script will re-add them on startup.

cp ${DATA_DIR}/cronjobs/* /etc/cron.d/
/etc/init.d/cron restart

exit 0

/data/cronjobs/ula-config

* * * * * root /bin/sh /data/ula/ula-config.sh

[borez]

@GentleHoneyLover

Thanks for this. I've tried multiple versions, but it still doesn't work. My /data/on_boot.d/25-add-cron-jobs.sh file is the same as yours.

Configuration in /data/cronjobs/backup

0 20 * * * root /bin/sh /data/backup.sh

Configuration in /data/backup.sh, 0755 permissions with chmod +x done. Running this file has no issues.

#!/bin/bash

cp /data/unifi/data/backup/autobackup/* /volume1/share/backup/UDMBackup/

Also, checking /var/log/cron.log also shows no activity of crontab loading.

[GentleHoneyLover]

@borez, can you double-check the corn restart command in /data/on_boot.d/25-add-cron-jobs.sh (third line from the bottom)? In my case I had to change it from whatever it was in the template to /etc/init.d/cron restart

[borez]

Thanks again for helping. I had factory reset my UDM PRO, and reinstalled the scripts. Apologies for the wrong mention earlier.

#!/bin/bash
# Get DataDir location
DATA_DIR="/data"
case "$(ubnt-device-info firmware || true)" in
1*)
   DATA_DIR="/mnt/data"
   ;;
2*)
   DATA_DIR="/data"
   ;;
3*)
   DATA_DIR="/data"
   ;;
*)
   echo "ERROR: No persistent storage found." 1>&2
   exit 1
   ;;
esac
## Store crontab files in ${DATA_DIR}/cronjobs/ (you will need to create this folder).
## This script will re-add them on startup.

cp ${DATA_DIR}/cronjobs/* /etc/cron.d/
# Older UDM's had crond, so lets check if its here if so use that one, otherwise use cron
if [ -x /etc/init.d/crond ]; then
 /etc/init.d/crond restart
elif [ -x /etc/init.d/cron ]; then
 /etc/init.d/cron restart
else
 echo "Neither crond nor cron found."
fi

exit 0

Running the script showed

Restarting cron (via systemctl): cron.service.

[isaacgonzalez77]

hi all, very helpful post! I also see No crontab for root, even though I manually copied cron files into /etc/cron.d . This is a new installation and I can't for the life of me find how to see pending cron jobs in that folder since they are systemwide, not user based. My cronjob is fairly simple(and no . characters in cron filename):
`0 23 * * * root /usr/bin/ssh [email protected] "swctrl poe set off id 5 ; swctrl poe set off id 1 ; swctrl poe set off id 4"

///edit: cron jobs working as expected. No issue thus far and working great for shutting down APs at nighttime.
`

[telnetdoogie]

I can also not get cron jobs working any more, I'm using 3.2.9.

If I ssh in and play around with systemctl stop cron and /usr/sbin/cron reload and systemctl restart cron then I can sometimes get it working albeit not reliably. I haven't figured out the secret handshake.

When I'm finally able to get cron jobs updated by restarting / reloading cron this way, it works, however it doesn't work as part of the on_boot scripts any more after a reboot.

Hoping I can figure this out, because I'd come to rely on it for SSL cert automation, and after a factory reset and resetup of onboot scripts, it's not been working for me any more.

[telnetdoogie]

update from my above comment...

Previously I was running scripts and always piping them IN THE CRONTAB to /usr/bin/logger so they'd leave their output in the /var/log/messages file.

for example:

MAILTO=""
* * * * * root echo "Hello this is in the messages log" | /usr/bin/logger

...Turns out that's no longer working, so I thought the cron jobs were not working. They are, however something has changed in cron in the latest OS I guess, where piping your output to logger no longer works. So, I just updated the .sh scripts that the cron jobs call to output to logger instead, and that works fine. cron jobs working as expected.

from some quick searches, looks like it might work if I were to do

MAILTO=""
* * * * * root /bin/bash -c 'echo "Hello this is in the messages log" | /usr/bin/logger'

..haven't tested that yet but it makes sense.

[boostchicken]

let us know how it works out Ubi rooted most of our hacks and killed them so much so I am pretty sure its on purpose. At least there us most features now.

I moved to MikroTik over this and while the UI might be the worst ever the device and the features are amazing and it competes with Ubi on price. I would recommend everyone do the same. Just my 2 cents on the matter

[telnetdoogie]

aww @boostchicken I wondered what happened to you!
The cron jobs are definitely working now, but yeah obviously it's a bit of a moving target these days.

Super appreciate everything you've done in this community! You've made my life better! Automation FTW!

[telnetdoogie]

from some quick searches, looks like it might work if I were to do

MAILTO=""
* * * * * root /bin/bash -c 'echo "Hello this is in the messages log" | /usr/bin/logger'

..haven't tested that yet but it makes sense.

...confirmed to also not work.

[telnetdoogie]

for anyone searching for this, it looks like the issue is with cron jobs interacting with /usr/bin/logger which no longer works, either by piping in the cron definition, or by modifying your scripts to send output there. Neither works.

I changed my cron entries to just output to a log file by using >> /data/scripts/some_log_file.log and so now I see evidence that they're running correctly and on time. So if in the past you've relied on the logger to output to /var/log/messages it looks like you can no longer do that.