Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 551352 - sys-process/cronie[anacron] doesn't run /etc/cron.{hourly,daily,weekly,monthly}/ scripts
Summary: sys-process/cronie[anacron] doesn't run /etc/cron.{hourly,daily,weekly,monthl...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal major with 1 vote (vote)
Assignee: Lars Wendler (Polynomial-C)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-06 07:00 UTC by Jaak Ristioja
Modified: 2019-11-03 15:01 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaak Ristioja 2015-06-06 07:00:13 UTC
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.
Comment 1 Mike Gilbert gentoo-dev 2015-06-06 16:03:49 UTC
Do you have the anacron USE flag enabled?
Comment 2 Jaak Ristioja 2015-06-06 16:51:58 UTC
(In reply to Mike Gilbert from comment #1)
> Do you have the anacron USE flag enabled?

Yes. "anacron inotify pam -selinux".
Comment 3 Alexander Tsoy 2015-09-26 13:40:47 UTC
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
Comment 4 SpanKY gentoo-dev 2015-09-26 14:48:53 UTC

*** This bug has been marked as a duplicate of bug 538864 ***
Comment 5 Alexander Tsoy 2015-09-26 19:45:47 UTC
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
Comment 6 Pavel Goran 2015-10-29 05:14:29 UTC
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.
Comment 7 Jan Chren (rindeal) 2016-01-15 21:11:59 UTC
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.
Comment 8 Gabriele Svelto 2016-02-25 14:40:01 UTC
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.
Comment 9 Jaak Ristioja 2016-02-27 11:27:26 UTC
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
Comment 10 Lars Wendler (Polynomial-C) gentoo-dev 2016-07-02 12:01:12 UTC
Patches are highly welcome. I still couldn't wrap my head around anacron unfortunately.
Comment 11 Gabriele Svelto 2016-09-28 08:41:18 UTC
This has been fixed in the last stable version of the cronie package (1.5.0-r1) so I suggest closing the bug.
Comment 12 Alexander Tsoy 2018-02-05 04:01:35 UTC
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
Comment 13 Jaak Ristioja 2018-04-26 22:08:04 UTC
1.5.1 seemed to work fine, but upgrading cronie to 1.5.1-r1 broke it again.
Comment 14 Alexander Tsoy 2018-04-26 22:39:56 UTC
(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.
Comment 15 Jaak Ristioja 2018-04-29 07:27:48 UTC
(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.
Comment 16 Serguei I. Ivantsov 2018-07-06 16:54:01 UTC
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
Comment 17 Jaak Ristioja 2018-07-09 22:04:47 UTC
(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
Comment 18 Jaak Ristioja 2018-11-25 22:42:24 UTC
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!
Comment 19 Maxxim 2019-10-28 09:09:11 UTC
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.
Comment 20 Lars Wendler (Polynomial-C) gentoo-dev 2019-10-28 09:12:24 UTC
(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?
Comment 21 Alexander Tsoy 2019-10-28 09:25:20 UTC
(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
Comment 22 Maxxim 2019-10-28 09:30:19 UTC
(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.
Comment 23 Larry the Git Cow gentoo-dev 2019-10-28 09:30:34 UTC
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(-)
Comment 24 Alexander Tsoy 2019-10-28 09:36:10 UTC
(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?
Comment 25 Alexander Tsoy 2019-10-28 10:08:17 UTC
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?
Comment 26 Maxxim 2019-10-28 15:18:55 UTC
(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.
Comment 27 Alexander Tsoy 2019-10-28 15:55:08 UTC
(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
Comment 28 Maxxim 2019-10-28 18:17:24 UTC
(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.
Comment 29 Lars Wendler (Polynomial-C) gentoo-dev 2019-11-03 15:01:52 UTC
(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?