Re: [Mailman-Users] Error running bin/mailmanctl restart
Mark has been helping me with this off-line but I thought I would send this to the list to see if there are others who are aware of the solution. I have been using the following on a clean install of Mac Server 10.5.8 and upgrading Mailman 2.1.9 to 2.1.12:
./configure --prefix=/usr/share/mailman --with-cgi-gid=_www --with-mail-gid=mail --with-mailhost=domain.com --with-urlhost=domain.com --with-var-prefix=/var/mailman --with-groupname=_mailmanand get the following error:
***** Installation directory /var/mailman is not configured properly!
***** Directory must be owned by group _mailman: /var/mailman /var/mailman is has the settings root:wheel while the files inside are root:_mailman.
Do I need to change the group of the /var/mailman directory for the install? I know that change is probably not significant, but I an not sure enough of my knowledge to know.
Once I get this right, I plan on upgrading a 10.6.2 production server running 2.1.12rc1 to 2.1.12.
Thanks!
Paul
Paul Kleeberg paul@fpen.org
On Dec 16, 2009, at 3:53 PM, Mark Sapiro wrote:
Paul Kleeberg wrote:
Mark has been helping me with this off-line
It wasn't my intent to go off-line, but if someone replies to me without including the list, I tend not to copy the list on further replies.
It is only significant to configure in your case, but configure whant the prefix and var_prefix directories to be SETGID and Mailman's group so that subordinates created by make install will be the same.
When you originally asked about this off line, I thought what you had would be OK because it was a working installation, but apparently it only works for Apple :(
You need to
chgrp _mailman /var/mailman chmod g+s /var/mailman
to make configure happy. The prefix directory (/usr/share/mailman in your case) needs to be the same.
Once I get this right, I plan on upgrading a 10.6.2 production server running 2.1.12rc1 to 2.1.12.
FYI, 2.1.13rc1 is released and 2.1.13 final will be released next week barring the unexpected. It fixes several minor bugs in 2.1.12.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I am ready to tear my hair out.
Thanks to Mark, I got mailman up and running except for one minor hitch. In my log file I see an endless stream of:
12/17/09 11:56:49 AM com.apple.launchd[1] (org.list.mailmanctl) Throttling respawn: Will start in 10 seconds
12/17/09 11:57:00 AM com.apple.launchd[1] (org.list.mailmanctl) Throttling respawn: Will start in 10 seconds Searching the archives, I found this (The thread starts at http://www.mail-archive.com/mailman-users@python.org/msg53952.html):
The only difference between my org.list.mailmanctl.plist and Apple's is my verb *start*, as opposed to Apple's *startf*. I'm baffled by *startf*, which is not supported by mailman and does nothing, either in the CLI or in org.list.mailmanctl.plist.
Further on down in the messages I read:
So I made that change to /System/Library/LaunchDaemons/org.list.mailmanctl.plist.
Everything appeared to work fine, web interface works, creating a list works but qrunner does not to appear to start on bootup. it appears that I now have to manually run:
sudo /usr/share/mailman/bin/mailmanctl start
to get mailman to start. That concerns me. I need to know how to get it to start on boot and how to restart itself if it dies.
When this is all done, I would be happy to summarize what I learned for http://wiki.list.org/pages/viewpage.action?pageId=4030530.
Paul
Paul Kleeberg paul@fpen.org
On Dec 17, 2009, at 9:35 AM, Mark Sapiro wrote:
--On December 17, 2009 1:21:35 PM -0600 Paul Kleeberg <paul@FPEN.ORG> wrote:
At one point, I compared the stock mailmanctl with that from the one Apple distributes with Mac OS X Server. The only difference was that the 'start' stanza in main() had been cloned as a 'startf' stanza, with a couple of relatively minor changes, primarily (if I remember correctly) to make it not daemonize, since things run from launchd aren't allowed to daemonize. I *think* that that's what's leading to the problem you see -- mailmanctl daemonizes, launchd cleans it up and it respawns, eventually triggering the error.
For my Mailman install on Mac OS X (client, not server) I gave up on using launchd to start Mailman at boot time, and just used an old-style StartupItem. I did make launchd scripts for all the Mailman stuff that's normally run out of cron; see the archives of this list for information about those.
In short, if you want to use launchd to start Mailman at boot time, I think that you're going to have to look at Apple's version of mailmanctl, and make equivalent changes to the stock mailmanctl to provide a 'startf' variant. If you do that, I urge you to try to do it in a cleaner way than Apple's hack -- my memory is that there were so few differences that it was a crime that they'd just duplicated the entire block of code and commented out parts.
NOTE: I was doing this comparison between the mailmanctl from Mac OS X Server 10.5, not 10.6, so it's possible that they cleaned up their act and did things differently. But a quick side-by-side compare of their mailmanctl and the stock one should get you pointed in the right direction.
-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910
On Dec 17, 2009, at 03:35 PM, Steve Burling wrote:
Could someone submit a bug on this here:
https://bugs.launchpad.net/mailman
I think it would be useful to support a "no-daemonize" option to the 'bin/mailman start' command in Mailman 3.
-Barry
--On December 17, 2009 4:12:29 PM -0500 Barry Warsaw <barry@list.org> wrote:
To which I reply:
Done.
-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910
On Thu, 17 Dec 2009, Steve Burling wrote:
I forgot about the deamonizing issue. But, it can sort of be worked around. In the note Paul quoted from, we have (and I am the "Me" in the quote; I forget who Bryan is):
With OnDemand set to false, launchctl thinks you want mailmanctl always running. But mailmanctl daemonizes and exits so launchctl tries to restart it. With my OnDemand set to true and RunAtLoad set to true, launchctl tries to run mailmanctl once at boot and is done with it. That mailmanctl exits is find. But it comes at the cost of launchctl not knowing anything about Mailman after mailmanctl exits. It won't restart it if it subsequently dies (has not been a problem for me. I have a cron job that runs hourly and e-mails me if a qrunner is missing not that one ever is once it's up and running).
But Paul mentioned that he tried OnDemand = true and RunAtLoad = true and no qrunners (Paul, did you reboot or force a reload of the launchd plist for mailman?). So we'd need to see log files as to what's happening. If there's nothing in any logfile (including system.log), then I'd guess the plist was never reloaded.
-- Larry Stone lstone19@stonejongleux.com
I recognize some of my words in what Paul has quoted below so let me comment. The discussion Paul is quoting from dealt with running Mailman on Mac OS X CLIENT whereas Paul is dealing with Mac OS X SERVER. OS X Server comes with a bastardized version of Mailman where as OS X Client has nothing except a Mailman account (Why is the account already there? Who knows!). The undocumented changes Apple has made have been talked about much before and I thought with the conclusion that the Apple provided version in Server is unsupported here due to the kind issues Paul is having.
My suggestion would be to remove the Apple provided version of Mailman, the install the official version from source. Once the Apple version is gone, I see no reason that instructions for installing from scratch that I've previously posted would not work. Heck, they might even work fine in parallel with the Apple version (which obviously then should not be allowed to run). I'm pretty sure, if I remember my own instructions correctly, that I have Mailman self-contained within /Applications/mailman except for the startup file in /Library/LaunchDaemons (which might need to be given a slightly different name to avoid a conflict), the modifications to the Apache configuration file, and the modifications to the Postfix configuration file for the aliases (all of which should be preserved by any Apple upgrades).
-- Larry Stone lstone19@stonejongleux.com
On Thu, 17 Dec 2009, Paul Kleeberg wrote:
Paul Kleeberg wrote:
Mark has been helping me with this off-line
It wasn't my intent to go off-line, but if someone replies to me without including the list, I tend not to copy the list on further replies.
It is only significant to configure in your case, but configure whant the prefix and var_prefix directories to be SETGID and Mailman's group so that subordinates created by make install will be the same.
When you originally asked about this off line, I thought what you had would be OK because it was a working installation, but apparently it only works for Apple :(
You need to
chgrp _mailman /var/mailman chmod g+s /var/mailman
to make configure happy. The prefix directory (/usr/share/mailman in your case) needs to be the same.
Once I get this right, I plan on upgrading a 10.6.2 production server running 2.1.12rc1 to 2.1.12.
FYI, 2.1.13rc1 is released and 2.1.13 final will be released next week barring the unexpected. It fixes several minor bugs in 2.1.12.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I am ready to tear my hair out.
Thanks to Mark, I got mailman up and running except for one minor hitch. In my log file I see an endless stream of:
12/17/09 11:56:49 AM com.apple.launchd[1] (org.list.mailmanctl) Throttling respawn: Will start in 10 seconds
12/17/09 11:57:00 AM com.apple.launchd[1] (org.list.mailmanctl) Throttling respawn: Will start in 10 seconds Searching the archives, I found this (The thread starts at http://www.mail-archive.com/mailman-users@python.org/msg53952.html):
The only difference between my org.list.mailmanctl.plist and Apple's is my verb *start*, as opposed to Apple's *startf*. I'm baffled by *startf*, which is not supported by mailman and does nothing, either in the CLI or in org.list.mailmanctl.plist.
Further on down in the messages I read:
So I made that change to /System/Library/LaunchDaemons/org.list.mailmanctl.plist.
Everything appeared to work fine, web interface works, creating a list works but qrunner does not to appear to start on bootup. it appears that I now have to manually run:
sudo /usr/share/mailman/bin/mailmanctl start
to get mailman to start. That concerns me. I need to know how to get it to start on boot and how to restart itself if it dies.
When this is all done, I would be happy to summarize what I learned for http://wiki.list.org/pages/viewpage.action?pageId=4030530.
Paul
Paul Kleeberg paul@fpen.org
On Dec 17, 2009, at 9:35 AM, Mark Sapiro wrote:
--On December 17, 2009 1:21:35 PM -0600 Paul Kleeberg <paul@FPEN.ORG> wrote:
At one point, I compared the stock mailmanctl with that from the one Apple distributes with Mac OS X Server. The only difference was that the 'start' stanza in main() had been cloned as a 'startf' stanza, with a couple of relatively minor changes, primarily (if I remember correctly) to make it not daemonize, since things run from launchd aren't allowed to daemonize. I *think* that that's what's leading to the problem you see -- mailmanctl daemonizes, launchd cleans it up and it respawns, eventually triggering the error.
For my Mailman install on Mac OS X (client, not server) I gave up on using launchd to start Mailman at boot time, and just used an old-style StartupItem. I did make launchd scripts for all the Mailman stuff that's normally run out of cron; see the archives of this list for information about those.
In short, if you want to use launchd to start Mailman at boot time, I think that you're going to have to look at Apple's version of mailmanctl, and make equivalent changes to the stock mailmanctl to provide a 'startf' variant. If you do that, I urge you to try to do it in a cleaner way than Apple's hack -- my memory is that there were so few differences that it was a crime that they'd just duplicated the entire block of code and commented out parts.
NOTE: I was doing this comparison between the mailmanctl from Mac OS X Server 10.5, not 10.6, so it's possible that they cleaned up their act and did things differently. But a quick side-by-side compare of their mailmanctl and the stock one should get you pointed in the right direction.
-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910
On Dec 17, 2009, at 03:35 PM, Steve Burling wrote:
Could someone submit a bug on this here:
https://bugs.launchpad.net/mailman
I think it would be useful to support a "no-daemonize" option to the 'bin/mailman start' command in Mailman 3.
-Barry
--On December 17, 2009 4:12:29 PM -0500 Barry Warsaw <barry@list.org> wrote:
To which I reply:
Done.
-- Steve Burling <mailto:srb@umich.edu> University of Michigan, ICPSR Voice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910
On Thu, 17 Dec 2009, Steve Burling wrote:
I forgot about the deamonizing issue. But, it can sort of be worked around. In the note Paul quoted from, we have (and I am the "Me" in the quote; I forget who Bryan is):
With OnDemand set to false, launchctl thinks you want mailmanctl always running. But mailmanctl daemonizes and exits so launchctl tries to restart it. With my OnDemand set to true and RunAtLoad set to true, launchctl tries to run mailmanctl once at boot and is done with it. That mailmanctl exits is find. But it comes at the cost of launchctl not knowing anything about Mailman after mailmanctl exits. It won't restart it if it subsequently dies (has not been a problem for me. I have a cron job that runs hourly and e-mails me if a qrunner is missing not that one ever is once it's up and running).
But Paul mentioned that he tried OnDemand = true and RunAtLoad = true and no qrunners (Paul, did you reboot or force a reload of the launchd plist for mailman?). So we'd need to see log files as to what's happening. If there's nothing in any logfile (including system.log), then I'd guess the plist was never reloaded.
-- Larry Stone lstone19@stonejongleux.com
I recognize some of my words in what Paul has quoted below so let me comment. The discussion Paul is quoting from dealt with running Mailman on Mac OS X CLIENT whereas Paul is dealing with Mac OS X SERVER. OS X Server comes with a bastardized version of Mailman where as OS X Client has nothing except a Mailman account (Why is the account already there? Who knows!). The undocumented changes Apple has made have been talked about much before and I thought with the conclusion that the Apple provided version in Server is unsupported here due to the kind issues Paul is having.
My suggestion would be to remove the Apple provided version of Mailman, the install the official version from source. Once the Apple version is gone, I see no reason that instructions for installing from scratch that I've previously posted would not work. Heck, they might even work fine in parallel with the Apple version (which obviously then should not be allowed to run). I'm pretty sure, if I remember my own instructions correctly, that I have Mailman self-contained within /Applications/mailman except for the startup file in /Library/LaunchDaemons (which might need to be given a slightly different name to avoid a conflict), the modifications to the Apache configuration file, and the modifications to the Postfix configuration file for the aliases (all of which should be preserved by any Apple upgrades).
-- Larry Stone lstone19@stonejongleux.com
On Thu, 17 Dec 2009, Paul Kleeberg wrote:
participants (5)
-
Barry Warsaw -
Larry Stone -
Mark Sapiro -
Paul Kleeberg -
Steve Burling