• [6.12.4] update_cron does not run during system start

    hawihoney

    By hawihoney

      • Minor

    Starting with 6.12.4 update_cron is no longer running during system start in a virtualized environment (Unraid VM). This worked until 6.11.5.

     

    Not running update_cron has impact on the User Scripts plugin that relies on that tool to add it's "Custom schedules" to "/etc/cron.d/root". So a scripts with "Custom schedules" attached, no longer runs from within the User Scripts plugin.

     

    One can work around this by calling update_cron manually after system start to add these missing entries in a second step.

     

    Here's a post that describes the problem. Diagnostics attached.

     

    Thanks for listening.

     

     

    On a barebone server it looks like that. This is missing on a virtualized server. Don't know if this is required to run over and over again for three times:

      

    root@Tower:~# grep -i cron /var/log/syslog
Sep  4 10:48:51 Tower crond[1870]: /usr/sbin/crond 4.5 dillon's cron daemon, started with loglevel notice
Sep  4 10:48:59 Tower root: Setting up cron for background notifications
***
*** The following lines are missing in a virtualized environment
***
Sep  4 10:51:16 Tower emhttpd: shcmd (270): rm -f /boot/config/plugins/dynamix/mover.cron
Sep  4 10:51:16 Tower emhttpd: shcmd (271): /usr/local/sbin/update_cron
Sep  4 14:35:29 Tower emhttpd: shcmd (219514): rm -f /boot/config/plugins/dynamix/mover.cron
Sep  4 14:35:29 Tower emhttpd: shcmd (219515): /usr/local/sbin/update_cron
Sep  4 14:35:49 Tower emhttpd: shcmd (219643): rm -f /boot/config/plugins/dynamix/mover.cron
Sep  4 14:35:49 Tower emhttpd: shcmd (219644): /usr/local/sbin/update_cron

     

    towervm01-diagnostics-20230906-0722.zip

    Go to reports Stable Releases

    User Feedback

    Recommended Comments

    itimpi

    There is also the possibility of a plugin that wants cron entries to be added to run this as part of installing the plugin (I know I do this for the Parity Check Tuning plugin).   

     

    Not sure whose responsibility it should be to run this, but it would never cause problems to run it redundantly and maybe plugins should not rely it being part of the start up sequence as I can see the 6.13 release needing significant changes to the start up sequence.

     

    Link to comment
    hawihoney
    47 minutes ago, itimpi said:

    There is also the possibility of a plugin that wants cron entries to be added to run this as part of installing the plugin (I know I do this for the Parity Check Tuning plugin).

     

    I can add update_cron as a user script (that's fired during array start) to the User Scripts plugin. This would be a workaround.

     

    Link to comment
    itimpi
    Just now, hawihoney said:

     

    I can add update_cron as a user script (that's fired during array start) to the User Scripts plugin. This would be a workaround.

     

     

    I agree, but it would be nice to know going forward whether firing this when needed should be the responsibility of plugins that need it, and if so they can then be updated to no longer need the workaround.

     

    Perhaps many people will not need the workaround anyway if they have a plugin (such as my Parity Check Tuning plugin) that issues this as part of its install process as the update_cron command is not plugin specific - it should pick up all cron jobs that any plugin has waiting to be activated.

    Link to comment
    hawihoney
    25 minutes ago, itimpi said:

    Perhaps many people will not need the workaround anyway if they have a plugin (such as my Parity Check Tuning plugin) that issues this as part of its install process as the update_cron command is not plugin specific - it should pick up all cron jobs that any plugin has waiting to be activated.

     

    I wrote @Squid in his User Scripts thread about our conversation here. Perhaps you both can talk about that (call update-cron during plugin installation).

     

    I only have 4 plugins installed on these machines, only what's really required on these. None of my plugins - except User Scripts - has to set schedules. And I don't want to install a plugin I don't need except for calling update_cron ;-) So I thiink it's up to this plugin to fix that. And if 6.13 will be picky during startup I think it's even more important to address that.

     

    Link to comment
    ljm42

    I can't reproduce this on any of my systems (bare metal or VM) but I agree the command is missing from your logs. Looking into it, although still open to ideas from other folks : )

    Link to comment
    hawihoney
    26 minutes ago, ljm42 said:

    update_cron is called by Unraid to enable `mover`, but User Shares are disabled on this server so `mover` is not needed.

     

    No User Shares, no Mover - it worked on 6.11.5, it stopped working with 6.12.4. This is a breaking change for e.g. plugins that rely on update_cron to add own schedules to cron.

     

    I will call update_cron as a User Script within User Scripts plugin to work around this change. No big deal for me, but be prepared for plugins or users that stumble over this change.

     

    BTW, why not call update_cron during system start always, just in case somebody needs it.

     

    Edited by hawihoney
    Link to comment
    ConnerVT

    I'll need to check again after I get home (and maybe tomorrow morning), but I did note my daily 4:00AM mover didn't seem to run this morning.  I had updated from 6.10.3 to 6.12.4 yesterday afternoon.

    Link to comment
    ConnerVT

    Just woke, and confirmed that mover did not run again this morning.  I was mistaken in my previous post, mover is scheduled daily at 2:20AM.  There is roughly 100GB that should have moved this morning.

     

    There is also a weekly User Script job that should run today (Thursdays) at 12:00 noon on a custom cron.  I won't change anything now and wait to see if that runs.

    malta-tower-diagnostics-20230907-0421.zip

    Link to comment
    Squid
    19 hours ago, ljm42 said:

    update_cron is called by Unraid to enable `mover`, but User Shares are disabled on this server so `mover` is not needed.

     

    If you enable User Shares then update_cron will be run when the array starts

    https://docs.unraid.net/unraid-os/manual/shares/user-shares/

    But that's wrong behaviour and a bug IMO @ljm42  update_cron should be run regardless if user shares are enabled or not.   The mover script should be intelligent enough to figure out that user shares are not enabled.  

     

    update_cron is an integral part of the OS, and many plugins rely upon it.  User Scripts, Parity Check Tuning, SSD Trim, CA, FCP etc etc. None of those require user shares to be enabled.

     

    It isn't mover related per se, but rather scans all .cron files within /config/plugins and adds them in unless the system runs in safe mode.

    Link to comment
    ljm42
    1 hour ago, Squid said:

    But that's wrong behaviour

     

    Agreed. Thanks for this report @hawihoney  

     

    So this has been the intended behavior for a long time, but due to a bug it was not actually working as intended. That bug was recently fixed and now it is clear that the intended behavior it is not actually what we want. This will be fixed in 6.13 to run regardless of whether User Shares are enabled or not.

     

     

    • Thanks 1
    Link to comment
    ConnerVT

    Some follow up information, and a question (or three):

     

    I have a few server housekeeping scripts, in User Scripts that run on custom cron schedules.  I just received notification from the one scheduled for today (Thursdays @ 1200).  However, I have gone two days without the mover running (automatically) on the server since updating from 6.10.3 to 6.12.4.  Never had this issue before.

     

    Is the mover issue I'm seeing related to what is being discussed here?  If so, would you propose a work around until it is resolved in 6.13?  If my issue isn't related, should I start a new thread in General Support?

    Link to comment
    Squid
    19 minutes ago, ConnerVT said:

    Is the mover issue I'm seeing related to what is being discussed here? 

    no

     

    20 minutes ago, ConnerVT said:

    should I start a new thread in General Support?

    yes

    • Like 1
    • Thanks 1
    Link to comment
    Squid

    All of my plugins that utilize any cron job are being updated today to automatically call update_cron when the array starts.

     

    The effect of this is that effectively only one of them has to wind up being installed and any plugin which uses cron will also wind up getting fixed.

    • Thanks 1
    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.

    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.