Red Hat Bugzilla – Bug 124208
mailman cron actions run even when disabled
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 Description of problem: Even when the mailman service is disabled, the /var/mailman/cron/crontab.in actions are still run. I assume they don't actually do anything except wake up and determine there is nothing to do, but I still think this needs to be fixed: * It uses a small amount of resources. * It clutters up /var/log/cron with a message every 5 minutes! * I'm trying to minimize power usage of the computer, and this makes it more difficult to spin down the disk. Of course I realize I can manually remove the crontab entry or remove the mailman package, but I shouldn't have to. I like the luxury of installing "everything" and only wasting cheap diskspace. Also, I want to have as few things to fiddle with when I next install/update Fedora. Version-Release number of selected component (if applicable): mailman-2.1.4-4 How reproducible: Always Steps to Reproduce: 1. Install complete FC2 (presumably just installing mailman is enough). 2. Disable mailman is the services configuration GUI. 3. Notice mailman entries in /var/log/cron - even after rebooting. Actual Results: Cron runs stuff for mailman every 5 minutes. Expected Results: If the mailman service is disabled, I would expect to see no mailman-related processes ever, either as daemons or started by cron. It should take zero resources beyond disk space. Additional info:
This seems like a valid request. I think the right approach to solving this is to only run the cron jobs if the mailman service is running. Since the servce is started and stopped with an init.d script we can install/remove the cron entries from the init.d script. Note technically mailman does not need to be running to perform some of the jobs scheduled with cron but in practical terms I can't imagine why someone would want to run the cron jobs without the service being enabled. I'm going to implement this approach now, unless somebody yells and says this is a bad idea.
fixed in mailman-2.1.5-13, cron jobs are now enabled on a service start and disabled on a service stop. They are no longer enabled as the result of package installation.
Small suggestion - instead of modifying the contents of /etc/cron.d/mailman, have InstallCron create that as a symlink to the real file and RemoveCron just rm the symlink. Makes it easier for people to figure out how to customize the cron job if they want to...
Hi Elliot: Yup, that was one of my first thoughts too but I was told that current versions of vixie cron won't for security reasons process cron files that are links. That sounded plausable to me as a security concern so I opted for the copy option instead.
Elliot has a good point about users being confused over which file to edit and their edits being wiped out. Since we can't link the file and have cron process it (my understanding is that for cron to process the the crontab file it must be owned by root, writable only by root, and not a link) that a reasonable compromise is to add a large clear comment at the top of the file explaining which file to edit and how to pick up the changes (e.g. restart).
Yeah, just adding docu on how to enable cron-jobs should be fine and way better to have "static" files in rpm than any self-modifying files... ;-)
In general Florian I would agree with you that admins who manage and set up mailman should read the doc and understand the process and that is preferable to a "self-modifying file". However, my concern is that Red Hat has shipped a mailman rpm that automatically manages the cron jobs for quite a while now. I suspect our customers will yell much more loudly over the sudden change and percieved and mysterious loss of functionality than they will over the nuance of which file to edit (that few ever edit and which by the way is now an actual file rather than being install by crontab, a change necessary for SELinux). I'm inclined to keep the previous automatic behavior of the rpm rather than confuse pre-existing customers, make sense?
O.K. mailman-2.1.5-14 now has more explicit crontab warnings and documentation in: /etc/init.d/mailman /etc/cron.d/mailman /var/mailman/cron/crontab.in