Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 184800 - incron/anacron replacement for sys-process/cronbase and fcrontab handling
Summary: incron/anacron replacement for sys-process/cronbase and fcrontab handling
Status: RESOLVED DUPLICATE of bug 162346
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Cron Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-10 01:50 UTC by Ryan Reich
Modified: 2007-07-14 20:17 UTC (History)
1 user (show)

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


Attachments
My proposed incron ebuild (incron-0.5.6-ebuild.tar.bz2,3.18 KB, application/octet-stream)
2007-07-10 01:52 UTC, Ryan Reich
Details
Diff of my ebuild against existing (empty) ebuild (incron.diff,8.32 KB, patch)
2007-07-10 12:22 UTC, Ryan Reich
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Reich 2007-07-10 01:50:44 UTC
I brought up recently (thread "Inotify and (f)crontabs") on the gentoo-dev mailing list a few issues I have with the current system for handling cron jobs:

a) sys-process/cronbase provides a default /etc/crontab to handle the directories /etc/cron.{hourly,daily,weekly,monthly}: it works by calling a script "run-crons" every ten minutes to check if any of these jobs need to be run, which is wasteful and generates many uninformative log messages from cron.  According to the discussion, this scheme was chosen to ensure that jobs which were to be run during system downtime are run as soon as possible after boot.  It should also be noted that run-crons itself is buggy in that it does not log the jobs it runs, so that the cron logs contain ONLY the notices of run-crons being run, and not of any of the actual tasks of interest.  It is not possible to prevent run-crons from being logged since some crons do not have the capability not to log particular jobs.

b) sys-process/fcron implements a similar scheme for handling "natural" configuration files (/etc/fcrontab and /etc/cron.d/*) by having /etc/fcrontab call, every ten minutes, a script check_system_crontabs to assemble (using fcrontab) a crontab for the (fictitious) user "systab" from these files whenever one is changed.  This is inefficient because they are unlikely to change very frequently, though of course when one changes it needs to take effect relatively quickly.

Issue a) can clearly be handled by anacron, since this is precisely the purpose for which it is intended; the argument made during the discussion was essentially that using anacron for this purpose is not worth the effort of configuring it; however, the necessary configuration is nearly identical to that which is already in place for sys-process/cronbase.  Using anacron will also obviate the need to run a job more than once a day and eliminate the redundant log messages.  (In my opinion, bugs like this, and the failure of run-crons to log its own jobs, are an inevitable consequence of a duplication of effort like run-crons which further justifies replacing it with a better-tested solution.)

However, anacron is redundant on an fcron-based system, and in addition my proposed solution for issue b) also solves issue a) when fcron is used.  My solution for b) is that the "incron" daemon, which currently has no ebuild in Portage, be used to monitor /etc/crontab, /etc/fcrontab, and /etc/cron.d/ for changes using the inotify facility available in recent 2.6 kernels.  When a change occurs, incron will invoke check_system_crontabs; thus, the system fcrontab will be regenerated immediately after any changes are indicated in /etc, and redundant runs of check_system_crontabs will be avoided.

Incron can also easily be adapted to handle the /etc/cron.{hourly,...} directories with the aid of a helper script: whenever a file is altered the helper script will create (or delete, as appropriate) a small fcrontab in /etc/cron.d which schedules a periodic (of the appropriate period) job invoking the altered file.  Since fcron has anacron's capabilities, this job can be made "anacron-like", which removes the need for anacron when fcron is installed and solves issue a) for such systems.

I have implemented this scheme on my machine and verified that it works.  I'm attaching an ebuild for incron which includes the relevant files that I've mentioned (an incrontab and my helper script, as well as a boot script for incron).  There does already exist a bug (#162346) which provides an ebuild for incron, though of course not with my additions.  My ebuild is different only in the completeness of the ebuild file itself and the absence of a patch for incron's Makefile; my ebuild corrects the same problems by passing variables to make, which I think is more robust since although as incron changes the Makefile may move completely out of sync with the patch, it is unlikely that the names of the variables will change (it also eliminates the need to maintain another file in the package and makes the changes quite explicit in the ebuild).  However, I don't care if my particular ebuild file is used; I include it only to provide a complete package for examination.

To summarize: the current solutions described in a) and b) are wasteful, sometimes buggy, and in principle incorrect.  Using incron+fcron (or anacron+any-other-cron) is the theoretically correct way to solve the problem, and additionally works quite a bit better.

Reproducible: Always

Steps to Reproduce:
Comment 1 Ryan Reich 2007-07-10 01:52:46 UTC
Created attachment 124392 [details]
My proposed incron ebuild
Comment 2 Ryan Reich 2007-07-10 01:53:29 UTC
Comment on attachment 124392 [details]
My proposed incron ebuild

Format: .tar.bz2
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2007-07-10 06:13:54 UTC
Please, attach a diff against current ebuild, no tarballs.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap2
Comment 4 Ryan Reich 2007-07-10 12:22:39 UTC
Created attachment 124415 [details, diff]
Diff of my ebuild against existing (empty) ebuild
Comment 5 SpanKY gentoo-dev 2007-07-12 03:21:42 UTC

*** This bug has been marked as a duplicate of bug 162346 ***
Comment 6 Ryan Reich 2007-07-14 19:21:07 UTC
I have to complain a little about this bug being marked a duplicate.  Bug 162346 is merely an ebuild for incron with no other contents or intents; this one concerns the cron system in general in addition to providing an ebuild.  I am afraid that this, which is the main point of the bug, will be lost since no one will give much priority to a "duplicate" bug and, perhaps, not even read it again.  Please reconsider, or, as I commented in the other bug, reverse the order of duplication.  Although the other one came first, mine is strictly more comprehensive.
Comment 7 SpanKY gentoo-dev 2007-07-14 19:53:01 UTC
you dont combine issues ... one bug per issue

Bug 162346 is about incron

anacron vs run-crons isnt bug worthy yet as that is still being hashed out on the mailing list (assuming there's even anything to change)
Comment 8 Ryan Reich 2007-07-14 20:17:05 UTC
I'm not combining issues.  I present a single issue: the cron setup is broken.  I then propose a solution: incron, ebuild provided.  I mention anacron as well because the incron solution ONLY makes sense for fcron (hence, anacron vs. run-crons is a feature of my solution to the bug, not a separate issue); however, you can take my report as a suggestion to remove cronbase as a dependency for fcron entirely and replace it with my incron ebuild, ignoring any anacron issues (I don't care about them anyway; I was just trying to be helpful).  My point is that if you let this bug go down as a duplicate of Bug 162346 its connection to the cron problem will be lost, someone will wonder why I included these weird script and config files, and then they'll reject my ebuild because they don't understand what it was intended for.  If they even read it, which seems unlikely since the ebuild of Bug 162346 has already made it into some kind of testing tree.

If this issue is still being debated on the mailing list I would like to participate.  However, the only such debate on gentoo-dev is the one I started, and it's been dead for a week; where is this debate taking place?  The reason I filed this bug is that I was advised to do so by Robert Buchholtz in that thread; the reason I didn't attach the patch to Bug 162346 is that I consider it to address a larger issue, and I didn't want to pollute that bug report with my own cause (one bug, one bug report?).