According to the ChangeLog, fcron-3.0.6-r1 removed /etc/crontab and uses fcrontab instead. Unfortunately, /etc/fcron/fcrontab, installed by fcron, contains only "check_system_crontabs -s 0", and is missing all the lines that used to exist in /etc/crontab that ran all the commands in /etc/cron.{hourly,daily,weekly,monthly}. That means those commands never get run any more. Reproducible: Always Steps to Reproduce:
Any news on this? btw: there should be fix to moving from absoleted dnotify to inotify as stated in http://www.gossamer-threads.com/lists/gentoo/performance/59775
This is somehow annoying. Even the emerge log tells you to do fcrontab -u systab /etc/crontab which is obviously useless since /etc/crontab doesn't exist. And I don't know how to get cron.{hourly,daily,weekly,monthly} working again w/o adding those lines from former /etc/crontab manually. check_system_crontabs doesn't recognize these cronjobs at all. A workaround is to downgrade to fcron-3.0.5-r2 since it is the last version installing /etc/fcron/crontab and running fcrontab -u systab /etc/fcron/crontab or optionally check_system_crontabs -v -i -f -C /etc/fcron/crontab -F /etc/fcron/fcrontab BTW: The emerge log output of fcron-3.0.5-r2 is also outdated: /etc/crontab and /etc/fcrontab have moved to /etc/fcron/ (for the latter file the log output is fixed in 3.0.6-r1)
It seems that problem is not in fcron itself, but in sys-process/cronbase. According to http://www.gentoo.org/doc/en/cron-guide.xml#doc_chap4 cronbase must install to /etc/crontab following entries: */15 * * * * test -x /usr/sbin/run-crons && /usr/sbin/run-crons 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly 0 3 * * * rm -f /var/spool/cron/lastrun/cron.daily 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly which in turn after fcron check_system_crontabs migrates to fcron system crontab. But cronbase simple does not do this. Any suggestions?
(In reply to comment #3) > It seems that problem is not in fcron itself, but in sys-process/cronbase. > According to http://www.gentoo.org/doc/en/cron-guide.xml#doc_chap4 cronbase > must install to /etc/crontab following entries: [...] If I remember rightly, /etc/crontab is not a file from sys-process/cronbase. But <sys-process/fcron-3.0.6-r1 brings this file ;-) Eg. on my older installation: # equery belongs /etc/crontab [ Searching for file(s) /etc/crontab in *... ] sys-process/fcron-3.0.4 (/etc/crontab) The chicken or the egg dilemma?
Also a problem on my system. It seems that whoever removed the install of /etc/crontab didn't realize that check_system_crontabs relies on it existing. I too found it interesting that http://www.gentoo.org/doc/en/cron-guide.xml#doc_chap4 claims that /etc/crontab should be installed by cronbase, because cronbase does no such thing. I noticed that the crontab file still exists in my fcron portage dir. So as a workaround one could link|copy /usr/portage/sys-process/fcron/files/crontab to /etc/crontab and check_system_crontabs would then pick it up.
(In reply to comment #5) [...] > I too found it interesting that > http://www.gentoo.org/doc/en/cron-guide.xml#doc_chap4 claims that /etc/crontab > should be installed by cronbase, because cronbase does no such thing. [...] My suggestion @cron-bugs: Do you want add the crontab file to 'sys-process/cronbase'?
IMO, "not running cron jobs" is a reasonably serious bug for a cron daemon. My machines are not having their logs rotated, they're not having database checks done on schedule, important things people rely on cron to do are not getting done. This bug is now over a year old, and all it would take in the near term to fix it is putting /etc/crontab back in fcron like it always was. I know package maintainers are both busy and volunteers, but could we perhaps get at least an official word on what the situation is? Is this going to be fixed soon? Is the proper solution for now to downgrade (if so, what if security holes show up in the old version)? Or should we all just accept that fcron is broken and will remain that way for a long time and we should go install a different scheduler?
(In reply to comment #7) > This bug is now over a year old *needs to get more sleep before reading datestamps* s/a year/three months/ but still, this is a serious bug.
Looks like nobody cares...
Or maybe who assigned the bug should have read the metadata.xml file correctly and _CCed me on the damn bug_. I'll work on it, sincerely I'd rather provide support for cron.* without having to deal with check_system_crontabs; fwiw what _I_ do on my systems to avoid the issue is adding this to fcrontab. 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly 1 3 * * * rm -f /var/spool/cron/lastrun/cron.daily 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly */10 * * * * /usr/bin/test -x /usr/sbin/run-crons && /usr/sbin/run-crons
As a quick workaround, running "fcrontab -u systab /etc/fcron/fcrontab" as root makes it operate correctly. This can be stated in -excessively long- einfo output.
Can I get your opinions on adding a "emerge --config" step that would set that up by itself?
Diego, any updates? I can poke at this one if you like.
Added fcron-3.0.6-r2.ebuild to reinstall crontab file in /etc Also recreated old crontab -> fcrontab symlink.
Assuming this is fixed; I no longer use fcron so cannot test, but there have been no comments to the contrary since it was claimed fixed five months ago.
I would prefer an fcron-style initial crontab to support our /etc/cron.d/ directories instead of the long elog advises to import any /etc/crontab. If migrating from vixie cron these hints could be useful to import the old crontabs to fcron. But for a new installation with fcron the /etc/cron.d/ directories should be supported without further administration. My first suggestion using fcron features, some load balancing (ok, this could be worse if correct execution time is mandatory): #@options,,LoadAvg1m,5m,15m,timeout freq command @nolog,first(5),lavg1(1.2),until(30) 1h run-parts /etc/cron.hourly @first(3h15),lavg1(1.2),until(12h) 1d run-parts /etc/cron.daily @first(4h30),lavg5(1.4),until(2d) 1w run-parts /etc/cron.weekly @first(5h45),lavg15(1.6),until(2d) 1m run-parts /etc/cron.monthly
