cronie-1.7.1-r1 does not trigger cron.weekly or cron.monthly anymore, at least not in "anacron-mode" means PC was off by the time

[AxelG-DE]

After upgrading sys-process/cronie from 1.7.0-r2 to 1.7.1-r1 (gentoo), cronie does not invoke any of my scripts or commands in /etc/cron.weekly (see Edit_4 for .weekly) or cron.monthly. This worked fine since the year 2019....

EDIT_1:

• the things in /etc/cron.daily do work
• I know, is also invoked by 0anacron in /etc/cron.d/hourly....
• I just checked my permissions of /etc/cron.* but they have not been changed since years:

ls -l | grep cron.

-rw-r--r--  1 root      root         541 20. Jan 10:39 anacrontab
drwxr-xr-x  2 root      root          38 28. Apr 2023  cron.d
drwxr-xr-x  2 root      root        4096 24. Nov 21:02 cron.daily
-rw-r--r--  1 root      root         148 20. Jan 10:39 cron.deny
drwxr-x---  2 root      root          93 17. Dez 13:53 cron.hourly
drwxr-x---  2 root      root         123 24. Nov 21:02 cron.monthly
-rw-r--r--  1 root      root         476 20. Jan 10:39 crontab
drwxr-x---  2 root      root         205 24. Nov 21:02 cron.weekly
-rw-r--r--  1 root      root         237 29. Apr 2021  mlocate-cron.conf

Edit_2 I have read this https://forums.gentoo.org/viewtopic-t-1108098-start-0.html and cannot find anything weird

Edit_3 I filed a downstream bug https://bugs.gentoo.org/923953

Edit_4 I kept analysing further:

• my appologies, I was too much relying on /var/log/rsnapshot (where I saw the issue first, as I observe my backup since recently my server's HDDs died and got replaced)

• so updated ground-truth: cron.weekly got invoked on Feb 2nd (partially) successfully there was an error, but I cannot nail it down. It said:

  Feb  2 20:01:00 brain anacron[10932]: Job `cron.weekly' locked by another anacron - skipping
  Feb  2 20:01:00 brain anacron[10932]: Normal exit (0 jobs run)
  Feb  2 20:09:11 brain anacron[27854]: Job `cron.daily' terminated (produced output)
  Feb  2 20:09:11 brain anacron[27854]: Job `cron.weekly' started
  Feb  2 20:17:10 brain anacron[27854]: Job `cron.weekly' terminated (exit status: 1) (produced output)

• cron.weekly got invoked or triggerd on Feb 4th, but didn't run well:

  Feb  4 04:22:00 brain CROND[30188]: (root) CMD ([ ! -f /etc/cron.hourly/0anacron ] && run-parts /etc/cron.weekly)
  Feb  4 04:22:00 brain CROND[30187]: (root) CMDEND ([ ! -f /etc/cron.hourly/0anacron ] && run-parts /etc/cron.weekly)

  why I say "didn't run well"? Because usually it says "Job `cron.weekly' started" or terminated, but not on the 4th (Sunday), where a normal cronjob should have run, if I am not mistaken

I studied a lot in the internet about anacrontab and cronie, but I still do not know, which day of the month, a monthly job should run if the machine is up and running

[t8m]

I do not see any reason for that. Could that be some change in the gentoo packages not in the upstream sources?

[AxelG-DE]

Currently I cannot tell, that there is something different in Gentoo. Cronie depends on sys-process/cronbase, which hasn't been updated since September 10th 2023. So the gentoo-guys potentially say the same just vice versa :)

To me it looks like the anacron function is not working anymore.

The only thing I could actually dig out is /etc/cron.hourly/0anacron has changed:

previous version (from my backup):

#!/bin/sh
# Check whether 0anacron was run today already
if test -r /var/spool/anacron/cron.daily; then
    day=`cat /var/spool/anacron/cron.daily`
fi
if [ `date +%Y%m%d` = "$day" ]; then
    exit 0
fi

# Do not run jobs when on battery power
online=1
for psupply in /sys/class/power_supply/* ; do
    if [ `cat "$psupply/type" 2>/dev/null`x = Mainsx ] && [ -f "$psupply/online" ]; then
        if [ `cat "$psupply/online" 2>/dev/null`x = 1x ]; then
            online=1
            break
        else
            online=0
        fi
    fi
done
if [ $online = 0 ]; then
    exit 0
fi
/usr/sbin/anacron -s

current version:

#!/bin/sh
# Check whether 0anacron was run today already
if test -r /var/spool/anacron/cron.daily; then
    day=`cat /var/spool/anacron/cron.daily`
fi
if [ `date +%Y%m%d` = "$day" ]; then
    exit 0
fi

# Check whether run on battery should be allowed
if test -r /etc/default/anacron; then
    . /etc/default/anacron
fi

if [ "$ANACRON_RUN_ON_BATTERY_POWER" != "yes" ]; then

    # Do not run jobs when on battery power
    online=1
    for psupply in /sys/class/power_supply/* ; do
        if [ `cat "$psupply/type" 2>/dev/null`x = Mainsx ] && [ -f "$psupply/online" ]; then
            if [ `cat "$psupply/online" 2>/dev/null`x = 1x ]; then
                online=1
                break
            else
                online=0
            fi
        fi
    done
    if [ $online = 0 ]; then
        exit 0
    fi

fi
/usr/sbin/anacron -s

I am not a pro for shell script but I cannot see anything super weird. On my system there is no /etc/default/anacron

[AxelG-DE]

maybe the line if [ "$ANACRON_RUN_ON_BATTERY_POWER" != "yes" ]; then

triggers the problem because the variable $ANACRON_RUN_ON_BATTERY_POWER isn't defined in this script...

and again not a script-pro, but 1= "yes" means not-on-battery, which I wonder is what is really really intended...

[AxelG-DE]

BTW: I have asked on IRC libera.chat #gentoo but I didn't get any reply on this typically very busy and competent channel

[AxelG-DE]

BTW: /etc/cron.daily works well, fwiw

[t8m]

Addition of this ANACRON_RUN_ON_BATTERY_POWER check was done before 1.7.0 though.

[t8m]

Try running the 0anacron or even edit it to add set -x to see what is actually evaluated/executed.

[AxelG-DE]

Addition of this ANACRON_RUN_ON_BATTERY_POWER check was done before 1.7.0 though.

you are right, I see on my backup on Jan17th, that this file 0anacron already looks like today and my weekly backup ran last time successfully on Jan 20th

[AxelG-DE]

Try running the 0anacron or even edit it to add set -x to see what is actually evaluated/executed.

with set -x

sh 0anacron

+ test -r /var/spool/anacron/cron.daily
++ cat /var/spool/anacron/cron.daily
+ day=20240206
++ date +%Y%m%d
+ '[' 20240206 = 20240206 ']'
+ exit 0

[AxelG-DE]

interestingly /var/spool/anacron/cron.weekly says: 20240202 but I do not have the "reaction" of rsnapshot of that day

[AxelG-DE]

/etc/anacrontab got touched on Jan 20th but diff shows, it is the same than in the past

[AxelG-DE]

As as also edited in the main issue, I filed a downstream bug: https://bugs.gentoo.org/923953

[AxelG-DE]

I will correct the link to downstream bug as soon as I'm back home

[AxelG-DE]

Done. Likely actually a gentoo issue acc to the gentoo bug tracking, but donno yet

[thesamesam]

I don't know what could've caused this on our end. We've had no other reports of it and the only difference between those cronie versions downstream was backporting the patches which landed upstream. No packaging changes otherwise.

[AxelG-DE]

I like the Avatar and the Nick :-)

back to the topic

• like you said downstream: more analysis is necessary and I would be happy to do so, if only I would know where to look
• I want to further understand anacrontab and will dig into documentation
• we/I found out already, that one part of my report was wrong, cron.weekly actually got invoked on Feb 2nd successfully and on Feb 4th unsuccessfully. So only cron.monthly might be missing (I will edit the initial issue here, if still possible)
• maybe there is a chance, we keep chatting on IRC and you guide me, what I could collect? (maybe not today and tomorrow as those are important days for my wife)
• I am fine to unmask cronie-1.7.1-r1r again and check, what I could do...

[AxelG-DE]

I am afraid, that all this issue is maybe due to wrong expectations based on my experience with vixie-cron. If that is the case, my apologies for the noise and I hope I did not lose all reputation for bug-reporting :)

I do understand, that cronie is partially working differently. However, from time to time I do invoke /etc/cron.daily or .weekly by hand.

• For daily it is easy anyhow next day it will run
• For weekly, I am rather sure that recently I triggered it manually in the middle of the week and it got invoked again in less than 7 days, so I assumed it will run always on the 7th day of the week = Sunday
• From all this, my assumption was, /etc/cron.monthly would have a default "run-day", let's assume 1st of a month (and what ever day comes later, when the PC was off by that time.
• But now I get the feeling (I wouldn't like to say understanding, as I still not fully know), weekly and monthly is always a certain delay to the respective last run (how big is the delay in case of @monthly?)

Unfortunately I didn't find a good (and official cronie-) documentation, which explains clear and simple, how the mechanism works (whereas vixie-cron with its crontab entries was self explanatory). One has to read thru different man pages. Maybe default in Linux but here a bit challenging, when you are not well into it...

I will unmask cronie-1.7.1-r1 and will observe it with my likely re-adjusted knowledge

[t8m]

This is what anacron does. Of course it would be possible to run the daily/weekly jobs at a fixed time/date if anacron was not used to run them.

[AxelG-DE]

please allow me to hold this issue open until next pass thru of cron.weekly and cron.monthly. I will close by then, if everything works as described here lately.

• yet I wish the connection between the many thingies wouldn't be that complicated and more transparent, but that is another issue
• what is the duration of cron.monthly, means how many days since last cron.monthly it will be re-run?

[t8m]

• what is the duration of cron.monthly, means how many days since last cron.monthly it will be re-run?

It depends on how many days this and the previous month had. So its at most 31days but can be 30, 28 or 29 (for February in leap years).

[AxelG-DE]

thank you everybody for patience....

this issue was false alarm, my apologies!!!

What happened:

• my backup NAS got broken recently (not related, explains my nervousness)
• once weekly backup actually failed (partially, cannot be analysed any more)
• I had "wrong" expectation about when "monthly" should actually happen at a fixed date in a month (which ideally get a much clearer documentation for end user)