public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Ryan Reich" <ryan.reich@gmail.com>
To: gentoo-user@lists.gentoo.org, gentoo-dev@lists.gentoo.org,
	gentoo-performance@lists.gentoo.org
Subject: [gentoo-dev] Inotify and (f)crontabs
Date: Sun, 1 Jul 2007 10:48:32 -0400	[thread overview]
Message-ID: <2bd962720707010748g6fcb96cfw47a85610aadc9f79@mail.gmail.com> (raw)

My apologies for triple-posting this.  I can't tell which list would
be most appropriate, since it is a user, development, and performance
issue (albeit a minor performance issue).

This is a small essay on Gentoo's setup for fcron.

My issue:
I just installed fcron and I have to say, I'm a little disappointed
with the kludgy mechanism for implmenting:
1. easy configuration, meaning I don't have to run fcrontab personally
2. /etc/cron.{hourly,daily,weekly,monthly}
These are implmented by some very silly-looking polling tricks which,
even in principle, will necessarily waste 83% (that's 5/6) of their
efforts and clutter the logs with useless and uninformative messages.

The facts:
1. is implmented by putting the following rule in /etc/fcrontab:
    @mail(false),nolog(true) 10 /usr/sbin/check_system_crontabs -s 0
whose effect is to run a script, every ten minutes, to check whether
I've changed any of the various configuration files /etc/{,f}crontab,
/etc/cron.d/* and then add them all to the system crontab.

2. is implmented by putting the following rules in /etc/crontab:
    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
whose effect is, at intevals of one hour, day, week, and month, to
remove some state files for the script run-crons, and also to run said
script every ten minutes.  The purpose of run-crons is to run the
scripts in /etc/cron.{hourly,...} at the appropriate intervals, thus
saving me the effort of adding a lot of lines looking like
    1 3 * * * * some-command
to my crontab.

Criticism:
Both of these ideas are, in principle and in practice, inefficient and
irritating.
1.  Since I will only ever update my crontabs rarely, checking every
ten minutes is likely to yield a negative result virtually 100% of the
time; however, since one wants the system to respond quickly when a
change is made, it is necessary to check frequently.  This would seem
to be a contradiction.

2.  The problem is even worse: though it is conceivable that a real
cron demon would be updating his crontabs willy-nilly, and thus that 1
is not actually inefficient for him, it is not possible, even in
principle, for 2 to be worthwhile.  run-crons runs commands at
intervals of no less than one hour, but is itself run every ten
minutes.  Furthermore, the files /var/spool/cron/lastrun/cron.* are
ALREADY handled in the run-crons script itself, so that most of the
above commands would seem to be redundant.  This one also has the
additional unpleasant property of filling the logs with useless
messages:
    [fcron] Job /usr/bin/test -x /usr/sbin/run-crons &&
/usr/sbin/run-crons started for user
    systab
and NOT actually logging the commands which are run (since they are
run by run-crons, which doesn't log)!  It seems that the reason for
this is that the option nolog(true) is invalid syntax for cron daemons
other than fcron, and /etc/crontab is not fcron-specific so the option
can't be passed there.  The reason that run-crons doesn't log is
unclear to me.

My solution:
It seems odd to me that Gentoo isn't following the advice in its own
scripts, since check_system_crontabs has a big comment on top advising
the user to run it with dnotify.  This would be a lovely solution,
since dnotify asks the kernel to inform it of directory changes and
thus, will only run the script when it needs to be run.  The only
problem is that you have to monitor the whole directory, and as the
comment notes, that will generate a lot of problems with /etc.

Dnotify, however, is obsoleted by inotify, which allows you to monitor
_individual_file_changes_.  Inotify is already in the kernel, so there
are no API changes to be made, just configuration changes to employ
inotify.  Furthermore, there exists a nice cron-like utility, based on
inotify, which performs exactly the tasks we want with fcron.  Its
name is incron and its page is here: http://inotify.aiken.cz.  I
hardly even need to explain how it would fit in, but here it is.
Rather than having /etc/fcrontab, one would simply have the following
in /etc/icron.d/fcron (say):
    /etc/crontab    IN_CLOSE_WRITE    /usr/sbin/check_system_crontabs -s 0
    /etc/fcrontab    IN_CLOSE_WRITE    /usr/sbin/check_system_crontabs -s 0
    /etc/cron.d    IN_CLOSE_WRITE,IN_CREATE
/usr/sbin/check_system_crontabs -s 0
Rather than having /etc/crontab, one would modify
check_system_crontabs to add lines like
    1 3 * * * * some-command
to the system crontab whenever /etc/cron.daily/some-command is
modified, and then add four more lines to /etc/icron.d/fcron:
    /etc/cron.hourly    IN_CLOSE_WRITE,IN_CREATE
/usr/sbin/check_system_crontabs -s 0
    /etc/cron.daily ....
The above problems are then all solved: the system crontab is updated
exactly when changes are made, wasteful polling is avoided, useless
syslogs are elided, and useful ones replace them.

I'm wondering now whether I should copy this letter to
fcrondev@ml.free.fr and ask them if they would like to include inotify
support in fcron itself, which would make configuration somewhat
easier and more flexible (also make incron unnecessary).  In any case,
I think the changes to Gentoo would be extremely easy to do and
improve life a little.

Thanks,
Ryan Reich
-- 
gentoo-dev@gentoo.org mailing list



             reply	other threads:[~2007-07-01 14:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01 14:48 Ryan Reich [this message]
2007-07-01 17:07 ` [gentoo-dev] Re: Inotify and (f)crontabs Daniel Schömer
2007-07-01 17:30   ` Ryan Reich
2007-07-01 19:20     ` [gentoo-dev] " Daniel Schömer
2007-07-04 17:19       ` Ryan Reich
2007-07-04 20:58         ` [gentoo-dev] " Daniel Schömer
2007-07-06  8:39         ` [gentoo-dev] Re: " Steve Long
2007-07-07 15:36           ` Ryan Reich
2007-07-09 21:43             ` Ryan Reich
2007-07-10  0:35               ` Robert Buchholz
2007-07-07  8:23 ` [gentoo-dev] " Mike Frysinger
     [not found]   ` <2bd962720707070847h2b1084f7lcb5b844fe9b8db70@mail.gmail.com>
2007-07-07 17:19     ` Ryan Reich
2007-07-07 18:13   ` Peter Gordon
2007-07-08  3:21     ` Mike Frysinger
2007-07-08  4:07       ` Ryan Reich
2007-07-08  4:22         ` Mike Frysinger
2007-07-08 10:46           ` [gentoo-dev] " Steve Long
2007-07-08 13:43             ` Ryan Reich
2007-07-08 13:50           ` [gentoo-dev] " Ryan Reich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2bd962720707010748g6fcb96cfw47a85610aadc9f79@mail.gmail.com \
    --to=ryan.reich@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=gentoo-performance@lists.gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox