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;
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
Version-Release number of selected component (if applicable):
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.
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...
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
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