Thanks Christian,

My sys admin skills are fairly dated/rusty (I am an architect and programmer). 
Either way, I am also an idiot. 

I left out one detail that might have helped. The behavior I am describing is 
jobs that are in /etc/cron.daily, etc. What I missed is that the default system 
crontab clearly puts anacron in control when it is installed. From the default 
crontab,“... test -x /usr/sbin/anacron || (cd / && run-parts --report 
/etc/cron.daily )"

Unfortunately, because I have rebuilt both of my Debian dev systems, I can’t 
say why 
everything worked as I thought it should. However, it appears that I didn’t 
anacron installed and the upgrade pulled it in. That is what caused the change 
behavior for my cron jobs in /etc/cron.daily. “apt purge anacron” fixes my 

Having said that, I am sure it is documented somewhere and I missed it, but 
anacron “own” jobs in /etc/cron.* surprised me.

Sorry to waste your time and thanks for all of your (and the other maintainers) 
hard work.

-- Tony Walker

> On Mar 14, 2019, at 2:24 AM, Christian Kastner <> wrote:
> Hi,
> On 13.03.19 20:16, Tony Walker wrote:
>> I upgraded to Buster from stretch and noticed that my cron jobs were
>> running at ~7:38 AM
>> instead of the time in my /etc/crontab. After some troubleshooting, I
>> did reinstall by
>> installing from 9.7 media followed immediately by apt full-upgrade. The
>> problem persisted.
>> I then did the same on a different system and found that the problem
>> exists on this
>> system as well (total of two out of two systems that exhibit the problem).
>> * What exactly did you do (or not do) that was effective (or
>> ineffective)?
>> I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times
>> (e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the
>> jobs always
>> run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone
>> is America/New_York
> that sounds extremely odd. I don't even have a clue what could cause
> this in the code. I'm almost certain it's not the job database...
> perhaps parsing?
> What does `journalctl -t CRON` say?  (If you don't use systemd, the
> default /etc/rsyslog.conf contains a line #cron ... that when you enable
> it, will log all cron messages to /var/log/cron.log).
> If those messages don't provide a clue, then the only thing I can think
> of is to rebuild in debug mode, and then to run cron in the foreground.
> It will then, quite verbosely, report about all the steps it takes. Let
> me know if you need such a build, I can provide you with one.
> Regards,
> Christian

Reply via email to