sys-process/cronie doesn't run /etc/cron.{hourly,daily,weekly,monthly}/ scripts by default as expected (I switched to cronie from vixie-cron and it stopped working). I'm not sure where the bug lies, but I found that a workaround is to chmod a-x /etc/cron.hourly/0anacron Very weird and unexpected indeed.
Do you have the anacron USE flag enabled?
(In reply to Mike Gilbert from comment #1) > Do you have the anacron USE flag enabled? Yes. "anacron inotify pam -selinux".
This is related to bug 538864. On my system I have: $ sudo diff -u /etc/config-archive/etc/crontab.dist /etc/crontab --- /etc/config-archive/etc/crontab.dist 2015-09-23 14:00:43.887450980 +0300 +++ /etc/crontab 2015-09-23 17:31:18.175762060 +0300 @@ -14,3 +14,6 @@ 19 4 * * 6 root [ ! -x /etc/cron.hourly/0anacron ] && rm -f /var/spool/cron/lastrun/cron.weekly 29 5 1 * * root [ ! -x /etc/cron.hourly/0anacron ] && rm -f /var/spool/cron/lastrun/cron.monthly */10 * * * * root [ ! -x /etc/cron.hourly/0anacron ] && { test -x /usr/sbin/run-crons && /usr/sbin/run-crons ; } + +# Run anacron hourly +01 * * * * root [ -x /etc/cron.hourly/0anacron ] && run-parts /etc/cron.hourly
*** This bug has been marked as a duplicate of bug 538864 ***
Well.. this is not actually a duplicate. The first point in bug #538864 is clearly a bug in cronie package, not a documentation bug. So it should be tracked separately here. Possible solutions: 1. Install contrib/0hourly into /etc/cron.d if anacron USE flag is enabled 2. Modify /etc/crontab as suggested in my previous comment
I have this issue as well. Just found out that one of my systems didn't run logrotate since January (when I switched from vixie-cron to cronie). Turned out that with default config, if /etc/cron.hourly/0anacron exists and is executable (as is the case with anacron enabled), nothing will ever run scripts from /etc/cron.daily, /etc/cron.hourly, etc.
For about 2 years now (#503634), emerging sys-process/cronie[anacron] silently prevents cron from working (except for cron.d jobs which are still run). Are there any intentions on fixing this? Or at least masking the USE flag, ewarn users, ... until that day comes? I'm calling here for an immediate action, because this issue already wasted too much time of too many people.
I've run into the same issue myself and it took me a while to realize that anacron wasn't being run. As with others I had a look under /var/log and noticed that no files had been rotated. It would be nice if this bug's state would be at least changed to CONFIRMED state since it has already affected multiple people.
I propose the default crontab lines be changed to this instead: 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 9 3 * * * root rm -f /var/spool/cron/lastrun/cron.daily 19 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 29 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly */10 * * * * root /usr/sbin/run-crons
Patches are highly welcome. I still couldn't wrap my head around anacron unfortunately.
This has been fixed in the last stable version of the cronie package (1.5.0-r1) so I suggest closing the bug.
This bug can be closed. It is not relevant anymore due to the following commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-process/cronie/files/cronie-1.3-crontab?id=c474dda61c900197ef05e64d1e5af35785cbb7c1
1.5.1 seemed to work fine, but upgrading cronie to 1.5.1-r1 broke it again.
(In reply to Jaak Ristioja from comment #13) Works for me. cron.hourly is run by cron and cron.{daily,weekly,monthly} is run by anacron.
(In reply to Alexander Tsoy from comment #14) > (In reply to Jaak Ristioja from comment #13) > Works for me. cron.hourly is run by cron and cron.{daily,weekly,monthly} is > run by anacron. I don't know about the details. Either way I have confirmed that with sys-process/cronie-1.5.1-r1 the default cron script for app-admin/logrotate in /etc/cron.daily/logrotate is not run (causing logs not being rotated properly and disk filling up). Downgrading to sys-process/cronie-1.5.1 solves the issue.
I've also got a similar issue, when most of my cron jobs (especially logrotate) stopped working. And I found a reason: Up to cronie version 1.5.1 the ebuild script installed a system crontab file, which contained all necessary entries to run hourly,daily,weekly and cron.monthly tasks: >cronie-1.3-crontab # check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 9 3 * * * root rm -f /var/spool/cron/lastrun/cron.daily 19 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 29 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly */10 * * * * root test -x /usr/sbin/run-crons && /usr/sbin/run-crons Since 1.5.1-r1 another system crontab file installed, and it contains just comments: >cronie-crontab # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed
(In reply to Serguei I. Ivantsov from comment #16) > # For details see man 4 crontabs Additionally, there is no section 4 manpage for crontabs, as cronie-1.5.1-r1 only installs /usr/share/man/man1/crontab.1.bz2 /usr/share/man/man5/anacrontab.5.bz2 /usr/share/man/man5/crontab.5.bz2 /usr/share/man/man8/anacron.8.bz2 /usr/share/man/man8/cron.8.bz2 /usr/share/man/man8/crond.8
Cronie 1.5.2 was just stabilized (see bug 671686) and I emerged it, but when portage prompted me to upgrade its configuration files I decided to stop using cronie because of this bug. I don't know whether 1.5.2 fixes this bug, but risking more breakage I do not want to try to find out. Its been over 3 years since I filed this bug and in my opinion this has not been well addressed. Since cron has become an even more critical component in the infrastructure I administer having to live with this bug has become unacceptable for me. Hence I have completely stopped using cronie and switched to another implementations which are hopefully more reliable. I'm sorry! Thanks to all who tried!
I analyzed this and tracked down the commit that messed things up: https://github.com/gentoo/gentoo/commit/f79f8ac5d95fa3f88301f0bad8b03e9d5f497a59 The intention is clearly stated in the commit message. However, the changes don't do what was intended. Shell script '/usr/sbin/run-crons' is what takes care of running jobs from '/etc/cron.*' folders. By removing run-crons from crontab, this functionality is disabled. As a result, '/etc/cron.hourly/0anacron' is no longer run. Thus, anacron is disabled, too. Now, nothing is running any jobs. The easiest fix, in my opinion, is to rollback the changes, i.e. restore crontab to: # /etc/crontab # Global variables SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # Check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 9 3 * * * root rm -f /var/spool/cron/lastrun/cron.daily 19 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 29 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly */10 * * * * root test -x /usr/sbin/run-crons && /usr/sbin/run-crons and disable USE flag 'anacron'. An alternative would be to add a single entry to crontab that runs /etc/cron.hourly/0anacron once per hour.
(In reply to Maxxim from comment #19) > I analyzed this and tracked down the commit that messed things up: > https://github.com/gentoo/gentoo/commit/ > f79f8ac5d95fa3f88301f0bad8b03e9d5f497a59 > > The intention is clearly stated in the commit message. However, the changes > don't do what was intended. > > Shell script '/usr/sbin/run-crons' is what takes care of running jobs from > '/etc/cron.*' folders. By removing run-crons from crontab, this > functionality is disabled. As a result, '/etc/cron.hourly/0anacron' is no > longer run. Thus, anacron is disabled, too. Now, nothing is running any jobs. > > The easiest fix, in my opinion, is to rollback the changes, i.e. restore > crontab to: > > # /etc/crontab > > # Global variables > SHELL=/bin/bash > PATH=/sbin:/bin:/usr/sbin:/usr/bin > MAILTO=root > HOME=/ > > # Check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly > 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly > 9 3 * * * root rm -f /var/spool/cron/lastrun/cron.daily > 19 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly > 29 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly > */10 * * * * root test -x /usr/sbin/run-crons && /usr/sbin/run-crons > > and disable USE flag 'anacron'. > > An alternative would be to add a single entry to crontab that runs > /etc/cron.hourly/0anacron once per hour. I'd like to keep the anacron USE flag. Do you mind providing an ebuild patch that fixes the issue?
(In reply to Maxxim from comment #19) > Shell script '/usr/sbin/run-crons' is what takes care of running jobs from > '/etc/cron.*' folders. By removing run-crons from crontab, this > functionality is disabled. As a result, '/etc/cron.hourly/0anacron' is no > longer run. Thus, anacron is disabled, too. Now, nothing is running any jobs. I think the real problem is that sys-apps/debianutils was moved to BDEPEND [1]. It provides run-parts binary that is needed by /etc/cron.d/0hourly [1] https://github.com/gentoo/gentoo/commit/1a8e9bee8c818f8b234f1e16105a77209a9612ad
(In reply to Alexander Tsoy from comment #21) > (In reply to Maxxim from comment #19) > > Shell script '/usr/sbin/run-crons' is what takes care of running jobs from > > '/etc/cron.*' folders. By removing run-crons from crontab, this > > functionality is disabled. As a result, '/etc/cron.hourly/0anacron' is no > > longer run. Thus, anacron is disabled, too. Now, nothing is running any jobs. > I think the real problem is that sys-apps/debianutils was moved to BDEPEND > [1]. It provides run-parts binary that is needed by /etc/cron.d/0hourly > > [1] > https://github.com/gentoo/gentoo/commit/ > 1a8e9bee8c818f8b234f1e16105a77209a9612ad Hm, interesting. However, I have sys-apps/debianutils installed, run-parts is present and still no jobs are being run.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=20783520eec8b8ba5cefed1b400c7254a0e94471 commit 20783520eec8b8ba5cefed1b400c7254a0e94471 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2019-10-28 09:29:57 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2019-10-28 09:30:29 +0000 sys-process/cronie: Move sys-apps/debianutils from BDEPEND to RDEPEND Thanks-to: Alexander Tsoy <alexander@tsoy.me> Bug: https://bugs.gentoo.org/551352 Package-Manager: Portage-2.3.78, Repoman-2.3.17 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-process/cronie/{cronie-1.5.4.ebuild => cronie-1.5.4-r1.ebuild} | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
(In reply to Maxxim from comment #22) > Hm, interesting. However, I have sys-apps/debianutils installed, run-parts > is present and still no jobs are being run. Then I have no idea what's wrong on your system. Do you see "run-parts /etc/cron.hourly" in your logs?
And another place to look at is /etc/cron.hourly/0anacron. It prevents anacron jobs from running if you are on buttery power, but maybe the check gives false positives on some systems?
(In reply to Alexander Tsoy from comment #25) > And another place to look at is /etc/cron.hourly/0anacron. It prevents > anacron jobs from running if you are on buttery power, but maybe the check > gives false positives on some systems? That was it, thank you, good find! Something else: the default /etc/crontab says # For details see man 4 crontabs but no such man page exists. I also tried 'man 4 crontab', 'man crontabs', nothing there.
(In reply to Maxxim from comment #26) > (In reply to Alexander Tsoy from comment #25) > > And another place to look at is /etc/cron.hourly/0anacron. It prevents > > anacron jobs from running if you are on buttery power, but maybe the check > > gives false positives on some systems? > > That was it, thank you, good find! So it works as expected? btw, upstream has the following fix, that may be useful: https://github.com/cronie-crond/cronie/commit/e7e7ad7286a8b27d3041963b3576c4c34c9395a9 > Something else: the default /etc/crontab says > > # For details see man 4 crontabs > > but no such man page exists. I also tried 'man 4 crontab', 'man crontabs', > nothing there. I think this line can be removed. crontabs.4 is available at [1], but it is for rhel/fedora as they are using their own run-parts, also available at [1]. [1] https://github.com/cronie-crond/crontabs
(In reply to Alexander Tsoy from comment #27) > (In reply to Maxxim from comment #26) > > (In reply to Alexander Tsoy from comment #25) > > > And another place to look at is /etc/cron.hourly/0anacron. It prevents > > > anacron jobs from running if you are on buttery power, but maybe the check > > > gives false positives on some systems? > > > > That was it, thank you, good find! > So it works as expected? Yes. I disabled the entire check for now. I'll try the fix you mentioned when I find some more time. > > Something else: the default /etc/crontab says > > > > # For details see man 4 crontabs > > > > but no such man page exists. I also tried 'man 4 crontab', 'man crontabs', > > nothing there. > I think this line can be removed. crontabs.4 is available at [1], but it is > for rhel/fedora as they are using their own run-parts, also available at [1]. > > [1] https://github.com/cronie-crond/crontabs Makes sense. So maybe @Lars Wendler can remove this in a second commit.
(In reply to Maxxim from comment #28) > Makes sense. So maybe @Lars Wendler can remove this in a second commit. See the following commit: https://gitweb.gentoo.org/repo/gentoo.git/diff/sys-process/cronie/files/cronie-crontab?id=59aabc7502b0c032bb48c86e89c9aaaa76b3ae6e So can we close this bug now?
No reply in over two years. Closing.
