Gentoo Archives: gentoo-user

From: Ryan Reich <ryan.reich@×××××.com>
To: gentoo-user@l.g.o, gentoo-dev@l.g.o, gentoo-performance@l.g.o
Subject: [gentoo-user] Inotify and (f)crontabs
Date: Sun, 01 Jul 2007 14:56:54
Message-Id: 2bd962720707010748g6fcb96cfw47a85610aadc9f79@mail.gmail.com
1 My apologies for triple-posting this. I can't tell which list would
2 be most appropriate, since it is a user, development, and performance
3 issue (albeit a minor performance issue).
4
5 This is a small essay on Gentoo's setup for fcron.
6
7 My issue:
8 I just installed fcron and I have to say, I'm a little disappointed
9 with the kludgy mechanism for implmenting:
10 1. easy configuration, meaning I don't have to run fcrontab personally
11 2. /etc/cron.{hourly,daily,weekly,monthly}
12 These are implmented by some very silly-looking polling tricks which,
13 even in principle, will necessarily waste 83% (that's 5/6) of their
14 efforts and clutter the logs with useless and uninformative messages.
15
16 The facts:
17 1. is implmented by putting the following rule in /etc/fcrontab:
18 @mail(false),nolog(true) 10 /usr/sbin/check_system_crontabs -s 0
19 whose effect is to run a script, every ten minutes, to check whether
20 I've changed any of the various configuration files /etc/{,f}crontab,
21 /etc/cron.d/* and then add them all to the system crontab.
22
23 2. is implmented by putting the following rules in /etc/crontab:
24 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
25 1 3 * * * rm -f /var/spool/cron/lastrun/cron.daily
26 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly
27 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly
28 */10 * * * * /usr/bin/test -x /usr/sbin/run-crons &&
29 /usr/sbin/run-crons
30 whose effect is, at intevals of one hour, day, week, and month, to
31 remove some state files for the script run-crons, and also to run said
32 script every ten minutes. The purpose of run-crons is to run the
33 scripts in /etc/cron.{hourly,...} at the appropriate intervals, thus
34 saving me the effort of adding a lot of lines looking like
35 1 3 * * * * some-command
36 to my crontab.
37
38 Criticism:
39 Both of these ideas are, in principle and in practice, inefficient and
40 irritating.
41 1. Since I will only ever update my crontabs rarely, checking every
42 ten minutes is likely to yield a negative result virtually 100% of the
43 time; however, since one wants the system to respond quickly when a
44 change is made, it is necessary to check frequently. This would seem
45 to be a contradiction.
46
47 2. The problem is even worse: though it is conceivable that a real
48 cron demon would be updating his crontabs willy-nilly, and thus that 1
49 is not actually inefficient for him, it is not possible, even in
50 principle, for 2 to be worthwhile. run-crons runs commands at
51 intervals of no less than one hour, but is itself run every ten
52 minutes. Furthermore, the files /var/spool/cron/lastrun/cron.* are
53 ALREADY handled in the run-crons script itself, so that most of the
54 above commands would seem to be redundant. This one also has the
55 additional unpleasant property of filling the logs with useless
56 messages:
57 [fcron] Job /usr/bin/test -x /usr/sbin/run-crons &&
58 /usr/sbin/run-crons started for user
59 systab
60 and NOT actually logging the commands which are run (since they are
61 run by run-crons, which doesn't log)! It seems that the reason for
62 this is that the option nolog(true) is invalid syntax for cron daemons
63 other than fcron, and /etc/crontab is not fcron-specific so the option
64 can't be passed there. The reason that run-crons doesn't log is
65 unclear to me.
66
67 My solution:
68 It seems odd to me that Gentoo isn't following the advice in its own
69 scripts, since check_system_crontabs has a big comment on top advising
70 the user to run it with dnotify. This would be a lovely solution,
71 since dnotify asks the kernel to inform it of directory changes and
72 thus, will only run the script when it needs to be run. The only
73 problem is that you have to monitor the whole directory, and as the
74 comment notes, that will generate a lot of problems with /etc.
75
76 Dnotify, however, is obsoleted by inotify, which allows you to monitor
77 _individual_file_changes_. Inotify is already in the kernel, so there
78 are no API changes to be made, just configuration changes to employ
79 inotify. Furthermore, there exists a nice cron-like utility, based on
80 inotify, which performs exactly the tasks we want with fcron. Its
81 name is incron and its page is here: http://inotify.aiken.cz. I
82 hardly even need to explain how it would fit in, but here it is.
83 Rather than having /etc/fcrontab, one would simply have the following
84 in /etc/icron.d/fcron (say):
85 /etc/crontab IN_CLOSE_WRITE /usr/sbin/check_system_crontabs -s 0
86 /etc/fcrontab IN_CLOSE_WRITE /usr/sbin/check_system_crontabs -s 0
87 /etc/cron.d IN_CLOSE_WRITE,IN_CREATE
88 /usr/sbin/check_system_crontabs -s 0
89 Rather than having /etc/crontab, one would modify
90 check_system_crontabs to add lines like
91 1 3 * * * * some-command
92 to the system crontab whenever /etc/cron.daily/some-command is
93 modified, and then add four more lines to /etc/icron.d/fcron:
94 /etc/cron.hourly IN_CLOSE_WRITE,IN_CREATE
95 /usr/sbin/check_system_crontabs -s 0
96 /etc/cron.daily ....
97 The above problems are then all solved: the system crontab is updated
98 exactly when changes are made, wasteful polling is avoided, useless
99 syslogs are elided, and useful ones replace them.
100
101 I'm wondering now whether I should copy this letter to
102 fcrondev@×××××××.fr and ask them if they would like to include inotify
103 support in fcron itself, which would make configuration somewhat
104 easier and more flexible (also make incron unnecessary). In any case,
105 I think the changes to Gentoo would be extremely easy to do and
106 improve life a little.
107
108 Thanks,
109 Ryan Reich
110 --
111 gentoo-user@g.o mailing list