My computer died in a power outage yesterday, and I discovered mailman did not start up correctly afterwards. Since at the moment it calls a: su - mailman -c 'bin/mailmanctl start' As long as the su succeeds, there will be no complaint. I think the system needs to at least check for master-qrunner.pid being a currently running process. It should either warn, or attempt a: su - mailman -c 'bin/mailmanctl -s start' Quick workaround is to have start and restart always use the -s parameter. But checking the pid file or the exit status of mailmanctl would be nice. Ideally, zap would actually do something, presumably same as -s - remove the stale lock and pid files, if any. Reproducible: Always Steps to Reproduce: 1. /etc/init.d/mailman start 2. terminate mailmanctl somehow with extreme prejudice 3. call start, stop, restart. doesn't matter. mailman will not work again. Actual Results: No mail delivery Expected Results: Started mailman Using mailman-2.1.3.ebuild
could you submit any patch ?
Well, the quick workaround is to add -s to the call to mailmanctl in the init.d script. That's what I'm doing on my computer and hardly seems to warrant creating a patch. I can, though, if you'd feel more comfortable. The more complex implementation of "zap" as well as testing for stale session on start, that I haven't done.
can confirm this behaviour. just had a power outage and this kept me busy for a while. the simplistic workaround would be to add the -s option to mailmanctl as kyberneticist suggested... cheers, tamer.
in cvs
