(sorry for the cross-post, but the potential audience for the proposal is quite large) (i'll start with a particular case, then develop the issue towards more general aspects) I'm looking at the clamav-db-0.72-1.1.fc2.dag package. It's pretty cleanly built (which is a feature of that entire repository, kudos to Dag Wieers!), however, my pet peeve with it is the freshclam cron job. By default, the package relies on the /etc/cron.daily/freshclam script to perform the update. That means the job is run whenever the cron.daily job is set to. FC2 by default sets cron.daily to run at 04:02 AM every day. Due to timezone dispersion, the clamav-db users of Dag's repository will run that cron job pretty much around the clock, but still all of them will run it at XX:02 - two minutes after :00 each hour. Yet still probably most of them are in timezone bunches: Northern America (3 timezones), Europe (about 2), parts of Asia (2...3 timezones) so the timezone dispersion is perhaps not as even as it seems. This will create artificial spikes on the ClamAV servers, making it more difficult for the ClamAV team to continue to provide the free service to the community. The problem is yet more alleviated somehow by the fact that database.clamav.net is a distributed database. Still the load spike problem still remains (it's just not as big). The solution to it is to spread the load created by all those .dag.i386.rpm users even further. However, changing the schedule of a job in /etc/cron.daily cannot be done by the sysadmin without affecting all other jobs in that directory. I think i have an improvement. Why use a file in /etc/cron.daily which has all those disadvantages (creates load spikes worldwide, it's hard to change) and not just stick a file in /etc/cron.d ? After all, that's what the FC2 MRTG package does, and it does it successfully. It's much easier to change: each file in /etc/cron.d can be adjusted to its own schedule. It's a lot more fine-grained: a sysadmin could configure it to run every hour, every half an hour, every 5 minutes on Fridays 13th or other weird combinations. Better yet, the %postinstall RPM macro could go ahead and fill up upon install a random 0...59 value for the minutes field and a random 0...23 value for the hour field, this way making things a lot easier for the ClamAV database servers. In fact, /etc/cron.d seems to be the ideal spot to stick cron jobs for RPM packages. There are very few applications that need cron jobs to be run exactly once a day/week/month in every conceivable situation, and most of those are actually within tightly interlocked sequences such as: run logwatch/webalizer first, then anacron, then finally logrotate. So, what i'm saying is, perhaps the authors of custom RPM packages (and even the non-custom ones, the ones included with the distribution) should use more aggresively /etc/cron.d to run the cron jobs for their packages. You get more flexibility, ease of administration, more intelligent behaviour of the system overall (see the automatic randomization of the schedule after installing the package). /etc/cron.daily confines the packages to quite tight limits; sometimes that's good (see above mention about cron sequences) but i believe it's usually not optimal. Sure, the sysadmin can change everything in a package, including the ways cron jobs are set. But, as i painfully noticed after upgrading my home server to FC2, the more you deviate from the trodden path, the more work you end up doing. Note: I believe (but i'm not sure) that crond must be notified after adding/removing a file to/from /etc/cron.d - if that's true, then any package adding/removing a script to/from /etc/cron.d should do a "service cron reload" in the %postinstall and %postun macros. That's not hard and it's actually an elegant solution. -- Florin Andrei http://florin.myip.org/
