• [6.6.4] No cron job running during the night


    Niklas
    • 6.6.5 Solved Urgent

    Hello,

     

    I have some cron jobs running during the night and morning every day. None of my cron job has run over the night, upgraded to 6.6.4 yesterday. No mover, no added backup script (using User Scripts), no daily trim and no Backup / Restore from CA.

    cat /etc/cron.d/root
    # Generated docker monitoring schedule:
    10 */6 * * * /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:
    0 3 * * * /usr/local/sbin/mover |& logger
    
    # Generated plugins version check schedule:
    10 */6 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null
    
    # Generated Unraid OS update check schedule:
    11 */6 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null
    
    # Generated ssd trim schedule:
    5 4 * * * /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

     

    root@Server:/etc# cd cron.daily/
    root@Server:/etc/cron.daily# v
    total 12
    -rwxrwxrwx 1 root root  76 Nov  8 00:08 fix.common.problems.sh*
    -rwxr-xr-x 1 root root 129 Apr 13  2018 logrotate*
    -rwxrwxrwx 1 root root  76 Nov  8 00:08 user.script.start.daily.sh*
    root@Server:/etc/cron.daily# cd ..
    root@Server:/etc# cd cron.hourly/
    root@Server:/etc/cron.hourly# v
    total 4
    -rwxrwxrwx 1 root root 77 Nov  8 00:08 user.script.start.hourly.sh*
    root@Server:/etc/cron.hourly# cd ../cron.weekly/
    root@Server:/etc/cron.weekly# v
    total 4
    -rwxrwxrwx 1 root root 77 Nov  8 00:08 user.script.start.weekly.sh*
    root@Server:/etc/cron.weekly# cd ../cron.monthly/
    root@Server:/etc/cron.monthly# v
    total 4
    -rwxrwxrwx 1 root root 78 Nov  8 00:08 user.script.start.monthly.sh*
    root@Server:/etc/cron.monthly#

    Just added my own backup script using "User Scripts" lately. No more, no less. :)

     

    Stuff supposed to be running here, nothing, except for fix common problems but that might be because of reboot after upgrade to .4.

    Capture_System_Log_-_Google_Chrome_2018-11-08_11-04-26_01625183.png.0a6dbbe1e710cbccd7b0c17daf618c4e.png

     

    Server%2FScheduler.png

     

    My added script:

    Capture_ServerUserscripts_-_Google_Chrome_2018-11-08_11-07-29_03478224.thumb.png.b87b62703aa3d5ab7502455368b67186.png

    Contents:

    #!/bin/bash
    cd /mnt/user/AppdataBackup
    /usr/local/bin/duplicacy prune -keep 0:5
    /usr/local/bin/duplicacy prune
    /usr/local/bin/duplicacy backup -stats -hash

     

    • Like 2
    • Upvote 2



    User Feedback

    Recommended Comments



    An older version of ‘dcron’ is included in Unraid 6.6.4 (actually the same version as used in Unraid 6.5.3).

    Need to investigate why it isn’t runnning as it did work with internal testing.

    • Upvote 1
    Link to comment

    Looks like I'm experiencing the same thing. 

     

    I don't understand the downgrade in priority.  I wouldn't call not running mover as scheduled just an "annoyance".  That's a pretty critical piece of caching for most.

     

    Guess it's back to 6.6.3....

    Link to comment
    14 minutes ago, limetech said:

    Changed Priority to Annoyance

    Not to argue, but I do think that this bug is urgent, and does require a special release just to fix it, without waiting for whatever else happens to be scheduled for 6.6.5

     

    It can potentially result in lost data due to the cache drive filling up, containers crashing, notifications not being sent etc.  Personally, I'm going to give this a day or two tops to be fixed, and then ultimately I'm going to have no choice but to downgrade back to 6.6.3, as I (and probably many users around here) are reliant upon notifications, scripts running on a schedule.

    • Upvote 1
    Link to comment

    Small annoyance. No off-site backups and drives filling up because no mover running. No ssd trimming. Yeah. I feel annoyed. 😉

     

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

     

    Well, let me disagree. 

    Edited by Niklas
    Link to comment

    I set to Annoyance because I was annoyed it was set to Urgent.  As it says in the sidebar, "Urgent" means causes a system crash or data loss (in the server), not that you feel the issue is urgent for you.  If that were the criteria, every issue is Urgent and let's just get rid of the priorities right?

    Link to comment
    3 minutes ago, brainbone said:

    Not moving data from cache drive to the drive pool as expected could lead to data loss.

    Not true

    Link to comment
    1 minute ago, bonienl said:

    Not true

    If you're not running a cache drive mirrored, yet expect data on the cache drive to be flushed to your protected drive pool nightly, but then a week down the line your unprotected cache drive dies, everything you expected to have been flushed to the protected drive pool but wasn't is now lost. 

     

    I would call that data loss.

     

    Link to comment
    2 minutes ago, bonienl said:

    Not true

    Wow.  I'm going to step back from this thread, as its going to quickly degrade.

    • Upvote 1
    Link to comment

    Urgent for ME? You are kidding, right? 

    Yes. Remove the priorities so no stupid, new, customer selects something that will get you annoyed. Wow. Nice feeling I got from this. First and last time I reported something regarding unraid. And yes! I still feel like this is urgent and not only to me (?? Do I really need to say this?) Maybe this is how people are treated in these forums, haven't been here for that long. Sorry if I stepped on someone's toes or something. Will absolutely not happen again! 

    • Upvote 1
    Link to comment

    Guys. Lets get this straight.

    It is a problem, so thank you for reporting this.

    And it needs to get resolved regardless of the priority set to it here.

     

    And the reason I answered "not true" is because a properly set up cache will overflow to the array. There is no data loss. It surely is 'inconvenient' that data stays on the cache longer than expected but this is NOT lost data.

     

    Link to comment
    54 minutes ago, Squid said:

    Not to argue, but I do think that this bug is urgent, and does require a special release just to fix it, without waiting for whatever else happens to be scheduled for 6.6.5

     

    It can potentially result in lost data due to the cache drive filling up, containers crashing, notifications not being sent etc.  Personally, I'm going to give this a day or two tops to be fixed, and then ultimately I'm going to have no choice but to downgrade back to 6.6.3, as I (and probably many users around here) are reliant upon notifications, scripts running on a schedule.

    What he said.  I’m just going to roll back and wait for the dust to settle.

    • Upvote 1
    Link to comment
    7 minutes ago, bonienl said:

    Guys. Lets get this straight.

    It is a problem, so thank you for reporting this.

    And it needs to get resolved regardless of the priority set to it here.

     

    And the reason I answered "not true" is because a properly set up cache will overflow to the array. There is no data loss. It surely is 'inconvenient' that data stays on the cache longer than expected but this is NOT lost data.

     

     

    The is a critical enough issue where you really should remove 6.6.4 from the stable release category. 

    Edited by brainbone
    Link to comment
    30 minutes ago, Niklas said:

    Urgent for ME? You are kidding, right? 

    Yes. Remove the priorities so no stupid, new, customer selects something that will get you annoyed. Wow. Nice feeling I got from this. First and last time I reported something regarding unraid. And yes! I still feel like this is urgent and not only to me (?? Do I really need to say this?) Maybe this is how people are treated in these forums, haven't been here for that long. Sorry if I stepped on someone's toes or something. Will absolutely not happen again! 

    You're right, and I personally apologize to you, and thank you for great report.  We'll get to the bottom of this asap.

    • Like 2
    Link to comment
    8 minutes ago, limetech said:

    You're right, and I personally apologize to you, and thank you for great report.  We'll get to the bottom of this asap.

     

    Accepted. Thanks. Let's move on. 🙂

    • Like 3
    Link to comment

    In 6.6.4 release we 'reverted' the cron package back to the one that was installed with 6.5.x releases in order to solve another bug.  However the way the cron daemon was started in that package is different and in 6.6.4 the problem is that crond is never started.

     

    We will publish a fix for this asap, and in meantime have taken down the 6.6.4 release.

     

    If you're running 6.6.4 you can type this command in a terminal window and put in your 'go' file as a workaround:

    /usr/sbin/crond -l notice

     

    • Like 2
    • Upvote 3
    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.