Bug 89250 - Wrong pid file in mailman initfile - and other info missing.
Summary: Wrong pid file in mailman initfile - and other info missing.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mailman
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: John Dennis
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-21 22:02 UTC by Trond Eivind Glomsrød
Modified: 2007-04-18 16:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-10 23:54:01 UTC

Attachments (Terms of Use)

Description Trond Eivind Glomsrød 2003-04-21 22:02:22 UTC
If you hack your way by the other critical bug in the package, you'll see that
the initscript doesn't work because the name of the pidfile is wrong. Start it
manually, look in the same dir and see the new name of pid file.

This initscript also lacks informative output, i18n for said output and a
condrestart statement.

Comment 1 John Dennis 2003-04-22 00:44:13 UTC
Thanks for pointing out the error in the initscript. I can see the names are
mismatched, which is an error in the upstream sources. But what I don't
understand is why this is creating a problem. To the best of my knowledge the
pidfile attribute should not be referenced by anything else in a Red Hat system.
I'll certainly fix it, but I'm wondering if you can tell me who is referencing
this? It's not in /etc/init.d/functions, pidof is a link to killall and killall
does not look at it, and service stop|start|restart all invoke mailmanctl which
knows how to find the pidfile via mm_cfg. Is this something you were doing by
hand because you saw it in the initscript or did you invoke something and had it
fail because of the filename mismatch?

Comment 2 Trond Eivind Glomsrød 2003-04-22 05:34:20 UTC
It showed up a couple of times when working on the system.... don't remember the
exact details, I was surprised myself. Ask Bill, initscripts are slightly magic.

Comment 3 John Dennis 2003-04-24 16:13:44 UTC
pidfile name is fixed both in our package and upstream.

The condrestart and i18n for the initscript seem like feature requests to me as
opposed to bugs.

The condrestart is optional according to Bill Nottingham, its not present in the
upstream package. A while ago I looked into adding this but as I recall it
turned out to be more work than seemed worth the effort. Sorry, I don't recall
the details but I seem to think it was because mailmanctl needed reworking to
properly deal with the pid.

I'm not sure what you want in terms of i18n in the initscript. I'm not aware of
other initscripts that are internationalized.

My inclination is not to invest further time on these two items but I want to
give you chance to comment.

Comment 4 Trond Eivind Glomsrød 2003-04-25 07:43:29 UTC
"condrestart" is optional in that it isn't necesarry for all packages. The
reason you need it (and why it's a  bug it's not in there now) is that you use
it to restart the running daemon on upgrade so the version with potential bugs
(usually security, as that is the most common reason for errata) is no longer

(and it's a real simple fix... just check for program running (pidfile), then
stop and start the program)

For a simple example, look at the dhcp package and the pre/post-uninstall
sections of those spec files.

As for i18n of other scripts, I suggest you look at them. They are all i18ned...
A simple example would be the dhcp package. Adding $ in front of the bash
strings and making sure to source the common init script funtions is a pretty
good start - and sufficient for this package. Ideally, use the standard strings
("Starting $prog: ") to share the strings used in the other packages.

You might take the opportunity to make sure the script behaves like the rest of
the scripts wrt. output as well.... output format etc. are standardized. 

Comment 5 John Dennis 2004-09-10 23:54:01 UTC
fixed in mailman-2.1.5-19

condrestart was added

mailmanctl still does a majority of the init.d script work and it's
strings are il18n'ed already. Added the il18n start and stop strings

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