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 for 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 system 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 have anacron installed and the upgrade pulled it in. That is what caused the change in behavior for my cron jobs in /etc/cron.daily. “apt purge anacron” fixes my problem. Having said that, I am sure it is documented somewhere and I missed it, but having 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 <c...@debian.org> 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
