I first posted in the userscripts as all scripts that used the cron scheduler were not firing.

I have now noticed my mover is not working and has not been for a week - 200GB of stuff is moving now after a manual move.

I suspect the unraid cron service is not working in for some reason.

I know a reboot / restart will probably fixed this, but I would prefer to not have to do that if possible.

 

Anyone able to help ?

post your diagnostics and the output of the following commands:

crontab -l
cat /etc/cron.d/root

 

Hi,

Thanks for the assist squid.

Here is all the stuff.

 

 

root@Tower:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

 

 

 

root@Tower:~# cat /etc/cron.d/root
# Generated docker monitoring schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php check &> /dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
45 3 * * * /usr/local/sbin/mover |& logger

# Generated parity check schedule:
30 0 1 * * /usr/local/sbin/mdcmd check NOCORRECT &> /dev/null || :

# Generated plugins version check schedule:
10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null

# Generated array status check schedule:
20 0,12 * * * /usr/local/emhttp/plugins/dynamix/scripts/statuscheck &> /dev/null

# Generated Unraid OS update check schedule:
11 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Generated cron settings for plugin autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

# CRON for CA background scanning of applications
29 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

# Generated ssd trim schedule:
0 5 * * * /sbin/fstrim -a -v | logger &> /dev/null

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null

# Generated schedules for parity.check.tuning
0 23 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
0 10 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/7 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
# Generated cron schedule for user.scripts
30 04 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/VW-ArchiveHomeMonitoring/script > /dev/null 2>&1
45 23 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/VW-Daily-FixPermissions-TVRecordings/script > /dev/null 2>&1
*/5 * * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/VW-Sync-Home_Monitoring_to_Hiddeen_Laptop/script > /dev/null 2>&1
30 23 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Weekly-unRAID-4TB-Backup/script > /dev/null 2>&1

 

 

 

 

 

tower-diagnostics-20211130-1030.zip

Update - 

I did not need all those tjhings in there as I am happy with the daily start time of the built in schedule - so I change a few to daily, and I left only two user scripts with cron type shedules - the 'every 5 minute' one and the nightly permissions fix at 23:45.

I noticed the 5 minute jobs started running - so all is well again I am assuming now.  

I have no idea why they all stopped 9 days ago - but there you are......

 

11 minutes ago, vw-kombi said:

I have no idea why they all stopped 9 days ago - but there you are......

I had an issue with the name (or maybe description) of a script I didn't follow those rules and the plugin does not give any feedback, it just blocker all scripts from running.

 

Quote

The name doesn't matter but it can only contain the following characters: letters ([A-Za-z]), digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), periods ("."), and spaces (" ")

from

 

But maybe it was not your issue.

Wouldn't have anything to do with mover.  I'd suggest a reboot.

As I said above - its fixed now.

I removed a load to the 'normal' naming (every day, every week etc).

Then it kicked in.

I had forgot all the usual ones that were not running that came through overnight also.

Plus it was parity check day overnight.