I know, I'm reopening a ten month old thread. But I think I have a good workaround.
On Fri, 26 Jun 2009, Sebastian Hagedorn wrote:
--On 26. Juni 2009 20:22:13 +0900 Matthias Schmidt beta@admilon.net wrote:
Am/On Thu, 18 Jun 2009 19:22:02 -0500 schrieb/wrote Larry Stone:
On 6/18/09 7:11 PM, Bryan Harrison at bryan@bryanharrison.com wrote:
I've built and installed Mailman 2.12 from current source code and have it running just fine under OS X Server 10.5.7, with on exception, which is not properly speaking a Mailman problem at all.
If I start Mailman from the CLI, using /usr/share/mailman/bin/ mailmanctl -s start, all is well.
If I allow launchd to start it S<caron>I get an endless succession ofS<caron>
Jun 18 16:50:26 org.list.mailmanctl[1697]: Starting Mailman's master qrunner. Jun 18 16:50:26 com.apple.launchd[1] (org.list.mailmanctl[1697]): Stray process with PGID equal to this dead job: PID 1698 PPID 1 Python Jun 18 16:50:26 com.apple.launchd[1] (org.list.mailmanctl): Throttling respawn: Will start in 9 seconds
The reason this happens is that launchd expects the processes it launches to stick around. They must not daemonize. But mailmanctl terminates after it has started the runners. I assume that Apple modified their own distribution of Mailman so that mailmanctl behaves differently. I'd suggest comparing the two.
I've been playing around with Mailman on a 10.6 (Snow Leopard) machine. It's for testing right now (at the next refresh of Mac Minis or iMacs, I plan to buy one to replace my PPC iMac that is currently my everything server - for now I'm testing on my laptop, the only Intel Mac I currently have).
So I found that unlike on the PPC iMac, where Mailman starts OK after about 75% of the boots, on the laptop, it consistently died. No "stray process" system.log message but perhaps that's a 10.5/10.6 difference. But I did see that the lock files were being created in $mailman_prefix/locks. So what's different? Well, the laptop is a lot faster. Factor? I think so.
I know almost nothing about the internals of forking processes and daemonizing but if I have it right, when 'mailmanctl start' is run, it forks a second copy which daemonizes. Meanwhile, the first copy of mailmanctl exits. My guess is that the first copy was exiting and the process terminating before the second copy had performed whatever magic it does to deamonize and run on its own. My workaround, which appears to work so far, is to have launchd, rather than run mailmanctl directly (via a .plist in /Library/LaunchDaemons), instead run a script in root's home directory that runs mailmanctl, then sleeps for one second before exiting: #!/bin/sh /usr/local/mailman/bin/mailmanctl -s start sleep 1
-- Larry Stone lstone19@stonejongleux.com