Bug 124208 - mailman cron actions run even when disabled
mailman cron actions run even when disabled
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mailman (Show other bugs)
2
i686 Linux
medium Severity low
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-24 14:45 EDT by Per Bothner
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-03 11:01:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Per Bothner 2004-05-24 14:45:01 EDT
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:
Comment 2 John Dennis 2004-09-01 16:16:37 EDT
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.
Comment 3 John Dennis 2004-09-02 15:36:05 EDT
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.
Comment 5 Elliot Lee 2004-09-02 16:45:58 EDT
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...
Comment 6 John Dennis 2004-09-02 16:54:43 EDT
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.
Comment 7 John Dennis 2004-09-02 17:16:17 EDT
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).
Comment 8 Florian La Roche 2004-09-02 17:19:16 EDT
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... ;-)
Comment 9 John Dennis 2004-09-02 18:02:35 EDT
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?
Comment 10 John Dennis 2004-09-03 11:01:46 EDT
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

Note You need to log in before you can comment on or make changes to this bug.