[Mailman-Users] Bug reported when creating a new list from webpage
Hi All Can anyone shed any light on this error I get when creating a new list from the webpage. (I can create lists okay from the newlist command) *** Displayed on the webpage *** - Bug in Mailman version 2.1.9 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. *** extract from the error log *** -- Jul 01 05:27:46 2008 (14663) command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) Jul 01 05:27:46 2008 admin(14663): admin(14663): [- Mailman Version: 2.1.9 -] admin(14663): [- Traceback --] admin(14663): Traceback (most recent call last): admin(14663): File /var/lib/mailman/scripts/driver, line 110, in run_main admin(14663): main() admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 56, in main admin(14663): process_request(doc, cgidata) admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 238, in process_request admin(14663): sys.modules[modname].create(mlist, cgi=1) admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 232, in create admin(14663): _update_maps() admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 60, in _update_maps admin(14663): raise RuntimeError, msg % (vcmd, status, errstr) admin(14663): RuntimeError: command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) admin(14663): [- Python Information -] admin(14663): sys.version = 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Unsubscribing
I am unsubscribing. Thanks very much for helping with my inquiry, Mark. The other queries don't apply to me, and I can offer no help with them. On my inquiry, one would think that an OS that wants to rule the world would be compatible with the most popular mailing list software. Oh, well... Doug. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Bls: mailman true virtual hosting
Did Mailman create a set of entries [EMAIL PROTECTED] abc [EMAIL PROTECTED] abc-admin ... Mailman doesn't create that set but Mailman create this set [EMAIL PROTECTED]abc-virtual.org [EMAIL PROTECTED]abc-virtual.org-admin in data/virtual-mailman and aliases abc-virtual.org: |/path/to/mail/mailman post abc-virtual.org abc-virtual.org-admin: |/path/to/mail/mailman admin abc-virtual.org ... in data/aliases If those virtual map and alias entries are there, it should work. mailman does not working ___ Yahoo! Toolbar kini dilengkapi dengan Search Assist. Download sekarang juga. http://id.toolbar.yahoo.com/ -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Unsubscribing
--On July 1, 2008 4:39:34 PM +1000 Doug Laidlaw [EMAIL PROTECTED] wrote: On my inquiry, one would think that an OS that wants to rule the world would be compatible with the most popular mailing list software. Oh, well... To which I reply: There is the source of your confusion. You are under the impression that Microsoft cares about how their software interacts with non-Microsoft products. They don't. You should just be using all Microsoft products, then everything would be good and right. Drink the Kool-Aid, Doug. -- Steve Burlingmailto:[EMAIL PROTECTED] University of Michigan, ICPSRVoice: +1 734 615.3779 330 Packard Street FAX: +1 734 647.8700 Ann Arbor, MI 48104-2910 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Unsubscribing
From: Doug Laidlaw [EMAIL PROTECTED] ... one would think that an OS that wants to rule the world would be compatible with the most popular mailing list software. Oh, well... Wow, you mean Microsoft is going to be compatible with Mailman? Cool! :-) Jesus Saves!... Passes to Gretsky; Gretsky SCORES! Jan Steinman http://www.VeggieVanGogh.com -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Bug reported when creating a new list from webpage
Mark Dale wrote: Can anyone shed any light on this error I get when creating a new list from the webpage. (I can create lists okay from the newlist command) *** extract from the error log *** -- Jul 01 05:27:46 2008 (14663) command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) Jul 01 05:27:46 2008 admin(14663): admin(14663): [- Mailman Version: 2.1.9 -] admin(14663): [- Traceback --] admin(14663): Traceback (most recent call last): admin(14663): File /var/lib/mailman/scripts/driver, line 110, in run_main admin(14663): main() admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 56, in main admin(14663): process_request(doc, cgidata) admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 238, in process_request admin(14663): sys.modules[modname].create(mlist, cgi=1) admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 232, in create admin(14663): _update_maps() admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 60, in _update_maps admin(14663): raise RuntimeError, msg % (vcmd, status, errstr) admin(14663): RuntimeError: command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) The issue is with ownership and/or permissions of virtual-mailman* When running create from the web, the process is running as the web server user and the mailman group because the create wrapper is group mailman and SETGID. When this user:group runs postmap, it fails as above. Permissions and ownership of the aliases* and virtual-mailman* files should be -rw-rw 1 rootmailman6308 Jun 21 12:51 aliases -rw-rw 1 mailman mailman 12288 Jun 21 12:51 aliases.db -rw-rw 1 apache mailman8051 Jun 21 12:51 virtual-mailman -rw-rw 1 mailman mailman 12288 Jun 21 12:51 virtual-mailman.db Note that all files are group writable and group mailman and the .db files (particularly aliases.db) are also owned by mailman. This latter controls the user (and that user's default group) that Postfix uses to run the pipes. The owner of aliases and virtual-mailman is not important. It may be root, apache or something else depending on who last created a list. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Python process size grows 30x in 8 hours (memory leak?)
An update - I've upgraded to the latest stable python (2.5.2) and its made no difference to the process growth: Config: Solaris 10 x86 Python 2.5.2 Mailman 2.1.9 (8 Incoming queue runners - the leak rate increases with this) SpamAssassin 3.2.5 At this point I am looking for ways to isolate the suspected memory leak - I am looking at using dtrace: http://blogs.sun.com/sanjeevb/date/200506 Any other tips appreciated! Initial (immediately after a /etc/init.d/mailman restart): last pid: 10330; load averages: 0.45, 0.19, 0.15 09:13:33 93 processes: 92 sleeping, 1 on cpu CPU states: 98.6% idle, 0.4% user, 1.0% kernel, 0.0% iowait, 0.0% swap Memory: 1640M real, 1160M free, 444M swap in use, 2779M swap free PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND 10314 mailman1 590 9612K 7132K sleep0:00 0.35% python 10303 mailman1 590 9604K 7080K sleep0:00 0.15% python 10305 mailman1 590 9596K 7056K sleep0:00 0.14% python 10304 mailman1 590 9572K 7036K sleep0:00 0.14% python 10311 mailman1 590 9572K 7016K sleep0:00 0.13% python 10310 mailman1 590 9572K 7016K sleep0:00 0.13% python 10306 mailman1 590 9556K 7020K sleep0:00 0.14% python 10302 mailman1 590 9548K 6940K sleep0:00 0.13% python 10319 mailman1 590 9516K 6884K sleep0:00 0.15% python 10312 mailman1 590 9508K 6860K sleep0:00 0.12% python 10321 mailman1 590 9500K 6852K sleep0:00 0.14% python 10309 mailman1 590 9500K 6852K sleep0:00 0.13% python 10307 mailman1 590 9500K 6852K sleep0:00 0.13% python 10308 mailman1 590 9500K 6852K sleep0:00 0.12% python 10313 mailman1 590 9500K 6852K sleep0:00 0.12% python After 8 hours: last pid: 9878; load averages: 0.14, 0.12, 0.13 09:12:18 97 processes: 96 sleeping, 1 on cpu CPU states: 97.2% idle, 1.2% user, 1.6% kernel, 0.0% iowait, 0.0% swap Memory: 1640M real, 179M free, 2121M swap in use, 1100M swap free PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND 10123 mailman1 590 314M 311M sleep1:57 0.02% python 10131 mailman1 590 310M 307M sleep1:35 0.01% python 10124 mailman1 590 309M 78M sleep0:45 0.10% python 10134 mailman1 590 307M 81M sleep1:27 0.01% python 10125 mailman1 590 307M 79M sleep0:42 0.01% python 10133 mailman1 590 44M 41M sleep0:14 0.01% python 10122 mailman1 590 34M 30M sleep0:43 0.39% python 10127 mailman1 590 31M 27M sleep0:40 0.26% python 10130 mailman1 590 30M 26M sleep0:15 0.03% python 10129 mailman1 590 28M 24M sleep0:19 0.10% python 10126 mailman1 590 28M 25M sleep1:07 0.59% python 10132 mailman1 590 27M 24M sleep1:00 0.46% python 10128 mailman1 590 27M 24M sleep0:16 0.01% python 10151 mailman1 590 9516K 3852K sleep0:05 0.01% python 10150 mailman1 590 9500K 3764K sleep0:00 0.00% python On 6/23/08 8:55 PM, Fletcher Cocquyt [EMAIL PROTECTED] wrote: Mike, many thanks for your (as always) very helpful response - I added the 1 liner to mm_cfg.py to increase the threads to 16. Now I am observing (via memory trend graphs) an acceleration of what looks like a memory leak - maybe from python - currently at 2.4 I am compiling the latest 2.5.2 to see if that helps - for now the workaround is to restart mailman occasionally. (and yes the spamassassin checks are the source of the 4-10 second delay - now those happen in parallel x16 - so no spikes in the backlog...) Thanks again On 6/20/08 9:01 AM, Mark Sapiro [EMAIL PROTECTED] wrote: Fletcher Cocquyt wrote: Hi, I am observing periods of qfiles/in backlogs in the 400-600 message count range that take 1-2hours to clear with the standard Mailman 2.1.9 + Spamassassin (the vette log shows these messages process in an avg of ~10 seconds each) Is Spamassassin invoked from Mailman or from the MTA before Mailman? If this plain Mailman, 10 seconds is a hugely long time to process a single post through IncomingRunner. If you have some Spamassassin interface like http://sourceforge.net/tracker/index.php?func=detailaid=640518group_id=103 atid=300103 that calls spamd from a Mailman handler, you might consider moving Spamassassin ahead of Mailman and using something like http://sourceforge.net/tracker/index.php?func=detailaid=840426group_id=103 atid=300103 or just header_filter_rules instead. Is there an easy way to parallelize what looks like a single serialized Mailman queue? I see some posts re: multi-slice but nothing definitive See the section of Defaults.py headed with # # Qrunner defaults # In order to run multiple, parallel IncomingRunner
Re: [Mailman-Users] Bls: mailman true virtual hosting
Dony Tata wrote: Did Mailman create a set of entries [EMAIL PROTECTED] abc [EMAIL PROTECTED] abc-admin ... Mailman doesn't create that set but Mailman create this set [EMAIL PROTECTED]abc-virtual.org [EMAIL PROTECTED]abc-virtual.org-admin in data/virtual-mailman and aliases abc-virtual.org: |/path/to/mail/mailman post abc-virtual.org abc-virtual.org-admin: |/path/to/mail/mailman admin abc-virtual.org ... in data/aliases You did not create the list properly. You created a list named abc-virtual.org. You did not create the list abc. If you have installed some patches that are supposed to provide true virtual hosting you need to talk to whoever developed those patches. If not, and this is straight GNU Mailman, you need to do the following in the mailman directory: bin/rmlist -a abc-virtual.org bin/newlist -e virtual.org -u www.virtual.org abc where www.virtual.org may be something else such as just virtual.org. It is the host name for the virtual.org web pages. In any case, with data/aliases entries like the above, the virtual-mailman entries should be like: [EMAIL PROTECTED]abc-virtual.org [EMAIL PROTECTED]abc-virtual.org-admin Otherwise you would have to actually mail to [EMAIL PROTECTED], etc. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Solaris 10 x86 Python 2.5.2 Mailman 2.1.9 (8 Incoming queue runners - the leak rate increases with this) SpamAssassin 3.2.5 At this point I am looking for ways to isolate the suspected memory leak - I am looking at using dtrace: http://blogs.sun.com/sanjeevb/date/200506 Any other tips appreciated! I'd start by installing 2.1.11, which was just released yesterday. MB -- e-mail: [EMAIL PROTECTED]/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ / \ HTML Email -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Feature Request: Selective Mass Subscription
Hi all, I am finally doing a followup on this. Mark asked me to vet his proposed solution to my ISP and see what they said. They actually took it quite seriously and discussed it. I just got a phone call from the head guy in that department who wanted to speak to me directly about it. (Mark, I'm sending you some private email with his contact info.) Basically, they are very concerned about spammers using their system. Their first response to my request was to wonder why I thought a spammer wouldn't be patient enough to add addresses to their lists slowly. After talking more with me, what he said was that he would be interested in the feature and would use it *IF* it could be turned on per list or per user, as opposed to a global on or off. He said he'd want to have a conversation with each listowner to make sure they really understood how to keep documentation proving how someone signed up for the list (email trail, paper from a signup sheet at an event, etc). He said he'd gladly turn on the feature for my lists after hearing that I knew how to do this. I pointed out to him that if it was per list, then I'd be bothering them every time I set up a new list (I have a lot of little ones). He agrees that per user would be much better, if it were possible. I said I'd heard hints (am I right?) that MM might be moving in that direction, allowing listowners to administer (or at least see) all their lists together. It would make life a lot easier if the ISP could simply say, okay, any list that Cyndi runs can have this new feature. So that's the feedback. Thanks for all your time with this. Cyndi Date: Tue, 24 Jun 2008 11:51:02 -0700 From: Mark Sapiro [EMAIL PROTECTED] Cyndi Norwitz wrote: Please let me know if I should post this elsewhere too. The Mass Subscribe feature has two settings: on and off. No it doesn't. My ISP has chosen to turn off Mass Subscribe. Only the invite feature is left. This is not a setting. It is a code modification done somewhere downstream of the Mailman project. My request is for an intermediate step that the provider can set. Something like subscribing one name at a time (so it's too much of a pain for a spammer to put in a thousand names) or up to 10 a day, or something that will make a large provider feel more comfortable but not completely remove the feature from the users. Turning off mass subscribe and leaving only mass invite is a modification not done by us. This request might better be directed to whoever made this modification. We fully sympathize with the difficulty and frustration of dealing with users who can't manage to successfully accept an invitation, and the problem of explaining to the VIP that the software doesn't allow this. I can see that actual site settings something like MAXIMUM_LIST_OWNER_SUBSCRIBES = 10 LIST_OWNER_SUBSCRIBE_WINDOW = days(7) to allow at most 10 subscribes in any 7 day period, might be an alternative that ISPs would use, but OTOH, I think that an ISP that choses to disable mass subscribe has likely done this in response to large ISP/email services that demand that lists be fully confirmed opt-in in order to be whitelisted, so they may not be willing to allow even that. Before I invest any effort in implementing such an option, I'd be interested in an opinion from your ISP as to whether they would use it. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The release notes and NEWS file for Mailman 2.1.11 contains the following innocuous looking item. ~- Improved bounce loop detection and handling in BounceRunner.py. This actually first appeared in 2.1.11rc2. It turns out this had an unintended consequence, but I actually think it is a good thing. The change involved bounces returned to the site list (mailman list) - -bounces address. There was always code in BounceRunner.py to look at bounces returned to the site list -bounces address to try to detect if the bounce was a bounce of a notice to a list owner, and if so, to send the bounce to the site list instead of processing it. This code never worked right. The main problem, is I don't in general know how to tell to what address the bounced message was originally sent. If I did, there would never be an unrecognized bounce. So part of the change in 2.1.11 rc2 and final is to just forward to the site list owner any message that arrives to the site list -bounces address so the owner can handle the bounce. The unintended consequence is that bounces of password reminders will also now go to the site list owner whereas before they were probably just ignored or processed as unrecognized bounces to the site list. Most of these bounces will probably be for dead addresses where the user disabled delivery and forgot about the list and the address died and the password reminders have been bouncing for a long time. In the longer term, plain text passwords and reminders are going away, but in the short term, the site list owner may get a lot of bounced password reminders (possibly a whole lot in a large site) on the first of the month following installation of this release. I think the best way to deal with these is to remove the dead addresses from the lists. Once this is done, the number of bounces on an ongoing basis should be small. - -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIanG8VVuXXpU7hpMRAg9UAKDa8+K8krlwftCWex/9HuGPV/yq8ACgkX0H /lXKKlzIU/aP2xOhE9K3H5k= =lOmt -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
The esteemed Mark Sapiro has said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The release notes and NEWS file for Mailman 2.1.11 contains the following innocuous looking item. ~- Improved bounce loop detection and handling in BounceRunner.py. This actually first appeared in 2.1.11rc2. It turns out this had an unintended consequence, but I actually think it is a good thing. The unintended consequence is that bounces of password reminders will also now go to the site list owner whereas before they were probably just ignored or processed as unrecognized bounces to the site list. Most of these bounces will probably be for dead addresses where the user disabled delivery and forgot about the list and the address died and the password reminders have been bouncing for a long time. In the longer term, plain text passwords and reminders are going away, but in the short term, the site list owner may get a lot of bounced password reminders (possibly a whole lot in a large site) on the first of the month following installation of this release. I think the best way to deal with these is to remove the dead addresses from the lists. Once this is done, the number of bounces on an ongoing basis should be small. Mark, I've snipped your message, but it brings up something that is a problem for us, and maybe hijacking your note with a feature request. We have a pattern of having list subscribers set themselves nomail, and sometime later, close out the ISP account that was used to receive mail. We would like to be able to cull out these moved/left no address subscribers. Evidently, 2.1.11 will allow me to more-or-less identify those accounts by telling me which accounts bounced the monthly reminder e-mail. It is not too great a task to look at perhaps ten accounts per month and correlate nomail by user with the bounce message. Over time, dead accounts add up. Last time I did something about this, I set all the nomail accounts to receive mail, and the bounce processor killed off close to half the accounts. This was after eight years of running. The problem with that was that I had a hundred or so users who were still active but who did not want to receive list mail. (Many were following the list through reading the archives). I'm also concerned about this proposed scheme to discontinue montnly mailings. It most definitely needs some mechanism whereby a user can reset or re-obtain their password without moderator intervention. Our user base is just plain not password-savvy, and I'm concerned about the increase in moderator workload if the recovery method is similar to password resetting by root (the Unix method). Hank -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Bug reported when creating a new list from webpage
- Pesan Asli Dari: Mark Sapiro [EMAIL PROTECTED] Kepada: [EMAIL PROTECTED]; Mailman-Users@python.org Terkirim: Selasa, 1 Juli, 2008 20:59:40 Topik: Re: [Mailman-Users] Bug reported when creating a new list from webpage Mark Dale wrote: Can anyone shed any light on this error I get when creating a new list from the webpage. (I can create lists okay from the newlist command) *** extract from the error log *** -- Jul 01 05:27:46 2008 (14663) command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) Jul 01 05:27:46 2008 admin(14663): admin(14663): [- Mailman Version: 2.1.9 -] admin(14663): [- Traceback --] admin(14663): Traceback (most recent call last): admin(14663): File /var/lib/mailman/scripts/driver, line 110, in run_main admin(14663): main() admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 56, in main admin(14663): process_request(doc, cgidata) admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 238, in process_request admin(14663): sys.modules[modname]..create(mlist, cgi=1) admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 232, in create admin(14663): _update_maps() admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 60, in _update_maps admin(14663): raise RuntimeError, msg % (vcmd, status, errstr) admin(14663): RuntimeError: command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) try to disable selinux... ___ Dapatkan situs lowongan kerja - Yahoo! Indonesia Search. http://id.search.yahoo.com/search?p=lowongan+kerjacs=bzfr=fp-top -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
* Mark Sapiro [EMAIL PROTECTED]: I am happy to announce the final release of the Mailman 2.1.11. I get lots of these: initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357:
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 1, 2008, at 2:40 PM, Hank van Cleef wrote: I'm also concerned about this proposed scheme to discontinue montnly mailings. It most definitely needs some mechanism whereby a user can reset or re-obtain their password without moderator intervention. Our user base is just plain not password-savvy, and I'm concerned about the increase in moderator workload if the recovery method is similar to password resetting by root (the Unix method). Don't worry, going forward we'll have a fairly typical password reset feature instead of the monthly reminder. The other advantage of this is that we won't have to keep user passwords in our database unencrypted. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhqfiIACgkQ2YZpQepbvXGgOACgphaPDxMRZ1E3bSO+NVVTqHxM 8ogAoKD9V1hQ18ZkTlHsAb0X7Ky5YVEr =cYvr -END PGP SIGNATURE- -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 1, 2008, at 2:42 PM, Ralf Hildebrandt wrote: * Mark Sapiro [EMAIL PROTECTED]: I am happy to announce the final release of the Mailman 2.1.11. I get lots of these: initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
* Mark Sapiro [EMAIL PROTECTED]: I am happy to announce the final release of the Mailman 2.1.11. Ralf Hildebrandt [EMAIL PROTECTED] replied: I get lots of these: initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2349: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2350: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2351: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2352: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2353: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2354: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2355: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2356: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization differ in signedness src/_koco_uhc.h:2357: warning: pointer targets in initialization
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
I'm having a hard time finding the release notes for 2.1.11 - can you please provide a link? (I want to see where it details any memory leak fixes since 2.1.9) thanks On 7/1/08 10:09 AM, Vidiot [EMAIL PROTECTED] wrote: Solaris 10 x86 Python 2.5.2 Mailman 2.1.9 (8 Incoming queue runners - the leak rate increases with this) SpamAssassin 3.2.5 At this point I am looking for ways to isolate the suspected memory leak - I am looking at using dtrace: http://blogs.sun.com/sanjeevb/date/200506 Any other tips appreciated! I'd start by installing 2.1.11, which was just released yesterday. MB -- Fletcher Cocquyt Senior Systems Administrator Information Resources and Technology (IRT) Stanford University School of Medicine Email: [EMAIL PROTECTED] Phone: (650) 724-7485 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
I'm having a hard time finding the release notes for 2.1.11 - can you please provide a link? (I want to see where it details any memory leak fixes since 2.1.9) Fletcher Cocquyt Senior Systems Administrator Information Resources and Technology (IRT) Stanford University School of Medicine There should be one on the list.org website. If not, I do not know where it is. Should also be in the package. MB -- e-mail: [EMAIL PROTECTED]/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ / \ HTML Email -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Not finding a leak ref - save a irrelevant (for this runner issue) admindb one: [EMAIL PROTECTED]:mailman-2.1.11 1:26pm 58 # ls ACKNOWLEDGMENTS Mailman README-I18N.enSTYLEGUIDE.txt configure doc misc templates BUGS Makefile.in README.CONTRIBTODO configure.in gnu-COPYING-GPL mkinstalldirs tests FAQ NEWS README.NETSCAPE UPGRADING contrib install-shscripts INSTALL READMEREADME.USERAGENT bin cron messages src [EMAIL PROTECTED]:mailman-2.1.11 1:26pm 59 # egrep -i leak * NEWS: (Tokio Kikuchi's i18n patches), 862906 (unicode prefix leak in admindb), Thanks On 7/1/08 1:05 PM, Vidiot [EMAIL PROTECTED] wrote: I'm having a hard time finding the release notes for 2.1.11 - can you please provide a link? (I want to see where it details any memory leak fixes since 2.1.9) Fletcher Cocquyt Senior Systems Administrator Information Resources and Technology (IRT) Stanford University School of Medicine There should be one on the list.org website. If not, I do not know where it is. Should also be in the package. MB -- Fletcher Cocquyt Senior Systems Administrator Information Resources and Technology (IRT) Stanford University School of Medicine Email: [EMAIL PROTECTED] Phone: (650) 724-7485 -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Mailman 2.1.11 final has been released.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Finkel wrote:
| * Mark Sapiro [EMAIL PROTECTED]:
| I am happy to announce the final release of the Mailman 2.1.11.
|
| Ralf Hildebrandt [EMAIL PROTECTED] replied:
| I get lots of these:
| initialization differ in signedness
| src/_koco_uhc.h:2349: warning: pointer targets in initialization
| differ in signedness
| src/_koco_uhc.h:2349: warning: pointer targets in initialization
| differ in signedness
snip
|
| Should I worry?
|
| When I build my 2.1.11 package for Ubuntu this morning I saw those
| (and others), and I did some research:
|
| -
| src/_koco_ksc5601.h:1493:
|
| static unsigned char *ksc5601_encode_page0[945] = { /* 0x00a1 -
0x0451 */
| \xa2\xae, 0, 0, \xa2\xb4, 0, 0, \xa1\xd7, \xa1\xa7,
|
| There is one message for each non-zero value (e.g., \xa2\xae).
|
| -
| src/_koco_uhc.h:1613:
|
| static unsigned char *uhc_encode_page0[11170] = { /* 0xac02 -
0xd7a3 */
|\x81\x41, \x81\x42, 0, \x81\x43, \x81\x44, 0, 0, 0,
|
| There is one message for each non-zero value (e.g., \xa2\xae).
| -
| src/koco_stream.h:42: warning: pointer targets in assignment differ in
signedness
| src/koco_stream.h:43: warning: pointer targets in assignment differ in
signedness
| srccur = s; [unsigned char = char]
| srcend = s + slen;[unsigned char = char + int]
|
| The same is true for lines 135 and 136.
| -
| And there are similar errors in a handful of other routines.
| -
|
| I have not yet installed my 2.1.11 package on my test machine, but
| my records show that I had the identical messages when I built my
| 2.1.9 package, which I use in production. I am not an expert in the
| C language and what type conversions are done. But I would not worry
| about these messages. I do not know if the C code can be changed to
| eliminate these messages.
Probably the code or some header declaration could be changed to avoid
these. I have in the past been able to produce them by giving the
'-pedantic' option to a gcc that didn't produce them by default.
The bottom line is that some versions of gcc will produce these
warnings, but they don't affect the operation of the installed codecs.
If these Japanese and Korean codecs were sticking around, we might look
into 'fixing' this, but Mailman 3.0 will require Python 2.5 minimum, and
~ These codecs have been built-in since Python 2.4 so Mailman's
installation of them will be going away.
- --
Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIaqf9VVuXXpU7hpMRAiEVAJ9uWoXsSsX3zq5E02pi21gilIMl0QCfWV/E
O+s1OlHE76J9nAM1zWwyiQw=
=/hFo
-END PGP SIGNATURE-
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Fletcher Cocquyt wrote: Not finding a leak ref - save a irrelevant (for this runner issue) admindb Nothing has been done in Mailman to fix any memory leaks. As far as I know, nothing has been done to create any either. If there is a leak, it is most likely in the underlying Python and not a Mailman issue per se. I am curious. You say this problem was exacerbated when you went from one IncomingRunner to eight (sliced) IncomingRunners. The IncomingRunner instances themselves should be processing fewer messages each, and I would expect them to leak less. The other runners are doing the same as before so I would expect them to be the same unless by solving your 'in' queue backlog, you're just handling a whole lot more messages. Also, in an 8 hour period, I would expect that RetryRunner and CommandRunner and, unless you are doing a lot of mail - news gatewaying, NewsRunner to have done virtually nothing. In this snapshot PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND 10123 mailman1 590 314M 311M sleep1:57 0.02% python 10131 mailman1 590 310M 307M sleep1:35 0.01% python 10124 mailman1 590 309M 78M sleep0:45 0.10% python 10134 mailman1 590 307M 81M sleep1:27 0.01% python 10125 mailman1 590 307M 79M sleep0:42 0.01% python 10133 mailman1 590 44M 41M sleep0:14 0.01% python 10122 mailman1 590 34M 30M sleep0:43 0.39% python 10127 mailman1 590 31M 27M sleep0:40 0.26% python 10130 mailman1 590 30M 26M sleep0:15 0.03% python 10129 mailman1 590 28M 24M sleep0:19 0.10% python 10126 mailman1 590 28M 25M sleep1:07 0.59% python 10132 mailman1 590 27M 24M sleep1:00 0.46% python 10128 mailman1 590 27M 24M sleep0:16 0.01% python 10151 mailman1 590 9516K 3852K sleep0:05 0.01% python 10150 mailman1 590 9500K 3764K sleep0:00 0.00% python Which processes correspond to which runners. And why are the two processes that have apparently done the least the ones that have grown the most. In fact, why are none of these 15 PIDs the same as the ones from 8 hours earlier, or was that snapshot actually from after the above were restarted? -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
On 7/1/08 3:37 PM, Mark Sapiro [EMAIL PROTECTED] wrote:
Fletcher Cocquyt wrote:
Not finding a leak ref - save a irrelevant (for this runner issue) admindb
Nothing has been done in Mailman to fix any memory leaks. As far as I
know, nothing has been done to create any either.
Ok, thanks for confirming that - I will not prioritize a mailman
2.1.9-2.1.11 upgrade
If there is a leak, it is most likely in the underlying Python and not
a Mailman issue per se.
Agreed - hence my first priority to upgrade from python 2.4.x to 2.5.2 (the
latest on python.org) - but upgrading did not help this
I am curious. You say this problem was exacerbated when you went from
one IncomingRunner to eight (sliced) IncomingRunners. The
IncomingRunner instances themselves should be processing fewer
messages each, and I would expect them to leak less. The other runners
are doing the same as before so I would expect them to be the same
unless by solving your 'in' queue backlog, you're just handling a
whole lot more messages.
Also, in an 8 hour period, I would expect that RetryRunner and
CommandRunner and, unless you are doing a lot of mail - news
gatewaying, NewsRunner to have done virtually nothing.
In this snapshot
PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND
10123 mailman1 590 314M 311M sleep1:57 0.02% python
10131 mailman1 590 310M 307M sleep1:35 0.01% python
10124 mailman1 590 309M 78M sleep0:45 0.10% python
10134 mailman1 590 307M 81M sleep1:27 0.01% python
10125 mailman1 590 307M 79M sleep0:42 0.01% python
10133 mailman1 590 44M 41M sleep0:14 0.01% python
10122 mailman1 590 34M 30M sleep0:43 0.39% python
10127 mailman1 590 31M 27M sleep0:40 0.26% python
10130 mailman1 590 30M 26M sleep0:15 0.03% python
10129 mailman1 590 28M 24M sleep0:19 0.10% python
10126 mailman1 590 28M 25M sleep1:07 0.59% python
10132 mailman1 590 27M 24M sleep1:00 0.46% python
10128 mailman1 590 27M 24M sleep0:16 0.01% python
10151 mailman1 590 9516K 3852K sleep0:05 0.01% python
10150 mailman1 590 9500K 3764K sleep0:00 0.00% python
Which processes correspond to which runners. And why are the two
processes that have apparently done the least the ones that have grown
the most.
In fact, why are none of these 15 PIDs the same as the ones from 8
hours earlier, or was that snapshot actually from after the above were
restarted?
Yes, I snapshot'ed the current leaked state, then restarted and snapped
those new PIDs to show the size diff.
Here is the current leaked state since the the cron 13:27 restart only 3
hours ago:
last pid: 20867; load averages: 0.53, 0.47, 0.24
16:04:15
91 processes: 90 sleeping, 1 on cpu
CPU states: 99.1% idle, 0.3% user, 0.6% kernel, 0.0% iowait, 0.0% swap
Memory: 1640M real, 77M free, 1509M swap in use, 1699M swap free
PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND
24167 mailman1 590 311M 309M sleep0:28 0.02% python
24158 mailman1 590 308M 305M sleep0:30 0.01% python
24169 mailman1 590 303M 301M sleep0:28 0.01% python
24165 mailman1 590 29M 27M sleep0:09 0.03% python
24161 mailman1 590 29M 27M sleep0:12 0.07% python
24164 mailman1 590 28M 26M sleep0:07 0.01% python
24172 mailman1 590 26M 24M sleep0:04 0.01% python
24160 mailman1 590 26M 24M sleep0:08 0.01% python
24162 mailman1 590 26M 23M sleep0:10 0.01% python
24166 mailman1 590 26M 23M sleep0:04 0.01% python
24171 mailman1 590 25M 23M sleep0:04 0.02% python
24163 mailman1 590 24M 22M sleep0:04 0.01% python
24168 mailman1 590 19M 17M sleep0:03 0.02% python
24170 mailman1 590 9516K 6884K sleep0:01 0.01% python
24159 mailman1 590 9500K 6852K sleep0:00 0.00% python
And the mapping to the runners:
[EMAIL PROTECTED]:mailman-2.1.11 4:16pm 66 # /usr/ucb/ps auxw | egrep mailman
| awk '{print $2 $11}'
24167 --runner=IncomingRunner:5:8
24165 --runner=BounceRunner:0:1
24158 --runner=IncomingRunner:7:8
24162 --runner=VirginRunner:0:1
24163 --runner=IncomingRunner:1:8
24166 --runner=IncomingRunner:0:8
24168 --runner=IncomingRunner:4:8
24169 --runner=IncomingRunner:2:8
24171 --runner=IncomingRunner:6:8
24172 --runner=IncomingRunner:3:8
24160 --runner=CommandRunner:0:1
24161 --runner=OutgoingRunner:0:1
24164 --runner=ArchRunner:0:1
24170 /bin/python
24159 /bin/python
Thanks for the analysis,
Fletcher
--
Mailman-Users mailing list
Mailman-Users@python.org
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Fletcher Cocquyt wrote:
Here is the current leaked state since the the cron 13:27 restart only 3
hours ago:
last pid: 20867; load averages: 0.53, 0.47, 0.24
16:04:15
91 processes: 90 sleeping, 1 on cpu
CPU states: 99.1% idle, 0.3% user, 0.6% kernel, 0.0% iowait, 0.0% swap
Memory: 1640M real, 77M free, 1509M swap in use, 1699M swap free
PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND
24167 mailman1 590 311M 309M sleep0:28 0.02% python
24158 mailman1 590 308M 305M sleep0:30 0.01% python
24169 mailman1 590 303M 301M sleep0:28 0.01% python
24165 mailman1 590 29M 27M sleep0:09 0.03% python
24161 mailman1 590 29M 27M sleep0:12 0.07% python
24164 mailman1 590 28M 26M sleep0:07 0.01% python
24172 mailman1 590 26M 24M sleep0:04 0.01% python
24160 mailman1 590 26M 24M sleep0:08 0.01% python
24162 mailman1 590 26M 23M sleep0:10 0.01% python
24166 mailman1 590 26M 23M sleep0:04 0.01% python
24171 mailman1 590 25M 23M sleep0:04 0.02% python
24163 mailman1 590 24M 22M sleep0:04 0.01% python
24168 mailman1 590 19M 17M sleep0:03 0.02% python
24170 mailman1 590 9516K 6884K sleep0:01 0.01% python
24159 mailman1 590 9500K 6852K sleep0:00 0.00% python
And the mapping to the runners:
[EMAIL PROTECTED]:mailman-2.1.11 4:16pm 66 # /usr/ucb/ps auxw | egrep mailman
| awk '{print $2 $11}'
24167 --runner=IncomingRunner:5:8
24165 --runner=BounceRunner:0:1
24158 --runner=IncomingRunner:7:8
24162 --runner=VirginRunner:0:1
24163 --runner=IncomingRunner:1:8
24166 --runner=IncomingRunner:0:8
24168 --runner=IncomingRunner:4:8
24169 --runner=IncomingRunner:2:8
24171 --runner=IncomingRunner:6:8
24172 --runner=IncomingRunner:3:8
24160 --runner=CommandRunner:0:1
24161 --runner=OutgoingRunner:0:1
24164 --runner=ArchRunner:0:1
24170 /bin/python
24159 /bin/python
What are these last 2? Presumably they are the missing NewsRunner and
RetryRunner, but what is the extra stuff in the ps output causing $11
to be the python command and not the runner option? And again, why are
these two, which presumably have done nothing, seemingly the biggest.
Here's some additional thought.
Are you sure there is an actual leak? Do you know that if you just let
them run, they don't reach some stable size and remain there as
opposed to growing so large that they eventually throw a MemoryError
exception and get restarted by mailmanctl.
If you allowed them to do that once, the MemoryError traceback might
provide a clue.
Caveat! I know very little about Python's memory management. Some of
what follows may be wrong.
Here's what I think - Python allocates more memory (from the OS) as
needed to import additional modules and create new objects. Imports
don't go away, but objects that are destroyed or become unreachable
(eg a file object that is closed or a message object whose only
reference gets assigned to something else) become candidates for
garbage collection and ultimately the memory allocated to them is
collected and reused (assuming no leaks). I *think* however, that no
memory is ever actually freed back to the OS. Thus, Python processes
that run for a long time can grow, but don't shrink.
Now, IncomingRunner in particular can get very large if large messages
are arriving, even if those messages are ultimately not processed very
far. Incoming runner reads the entire message into memory and then
parses it into a message object which is even bigger than the message
string. So, if someone happens to send a 100MB attachment to a list,
IncomingRunner is going to need over 200MB before it ever looks at the
message itself. This memory will later become available for other use
within that IncomingRunner instance, but I don't think it is ever
freed back to the OS.
Also, I see very little memory change between the 3 hour old snapshot
above and the 8 hour old one from your prior post. If this is really a
memory leak, I'd expect the 8 hour old ones to be perhaps twice as big
as the 3 hour old ones.
Also, do you have any really big lists with big config.pck files. If
so, Runners will grow as they instantiate that (those) big list(s).
--
Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Bug reported when creating a new list from webpage
That's great Mark, many thanks. Just recapping for anyone else's interest. -- After installing Mailman, when first attemping to create a new list using the webpage - it returned a You don't have permission. (Creating a new list from the terminal was working okay) This was fixed by running: sudo mmsitepass -c myNewPassword and restarting: sudo /etc/init.d/mailman restart Then, when trying to create a new list from the webpage, it returned an error Bug in Mailman ... This was fixed by settig correct permissions and group/owner on the files as Mark explained. % /var/lib/mailman/data: ll total 76 drwxrwsr-x 2 root list 4096 Jul 1 06:19 . drwxrwsr-x 9 root list 4096 Jun 30 04:33 .. -rw-rw 1 root list 1865 Jul 1 06:19 aliases -rw-rw-r-- 1 list list 12288 Jul 1 06:19 aliases.db -rw-rw 1 list list 4719 Jul 1 06:06 bounce-events-14733.pck -rw-r- 1 root list41 Jul 1 05:26 creator.pw -rw-rw-r-- 1 list list 1620 Jun 30 05:01 heldmsg-testlist-1.pck -rw-rw-r-- 1 root list10 Jun 30 04:33 last_mailman_version -rw-r--r-- 1 root list 14114 Mar 7 05:22 sitelist.cfg -rw-rw 1 www-data list 1314 Jul 1 06:19 virtual-mailman -rw-rw 1 list list 12288 Jul 1 06:19 virtual-mailman.db % /var/lib/mailman/data: sudo /etc/init.d/mailman restart -- Mark Sapiro wrote: Mark Dale wrote: Can anyone shed any light on this error I get when creating a new list from the webpage. (I can create lists okay from the newlist command) *** extract from the error log *** -- Jul 01 05:27:46 2008 (14663) command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) Jul 01 05:27:46 2008 admin(14663): admin(14663): [- Mailman Version: 2.1.9 -] admin(14663): [- Traceback --] admin(14663): Traceback (most recent call last): admin(14663): File /var/lib/mailman/scripts/driver, line 110, in run_main admin(14663): main() admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 56, in main admin(14663): process_request(doc, cgidata) admin(14663): File /usr/lib/mailman/Mailman/Cgi/create.py, line 238, in process_request admin(14663): sys.modules[modname].create(mlist, cgi=1) admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 232, in create admin(14663): _update_maps() admin(14663): File /usr/lib/mailman/Mailman/MTA/Postfix.py, line 60, in _update_maps admin(14663): raise RuntimeError, msg % (vcmd, status, errstr) admin(14663): RuntimeError: command failed: /usr/sbin/postmap /var/lib/mailman/data/virtual-mailman (status: 1, Operation not permitted) The issue is with ownership and/or permissions of virtual-mailman* When running create from the web, the process is running as the web server user and the mailman group because the create wrapper is group mailman and SETGID. When this user:group runs postmap, it fails as above. Permissions and ownership of the aliases* and virtual-mailman* files should be -rw-rw 1 rootmailman6308 Jun 21 12:51 aliases -rw-rw 1 mailman mailman 12288 Jun 21 12:51 aliases.db -rw-rw 1 apache mailman8051 Jun 21 12:51 virtual-mailman -rw-rw 1 mailman mailman 12288 Jun 21 12:51 virtual-mailman.db Note that all files are group writable and group mailman and the .db files (particularly aliases.db) are also owned by mailman. This latter controls the user (and that user's default group) that Postfix uses to run the pipes. The owner of aliases and virtual-mailman is not important. It may be root, apache or something else depending on who last created a list. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Mark Sapiro wrote: Which processes correspond to which runners. And why are the two processes that have apparently done the least the ones that have grown the most. and What are these last 2? Presumably they are the missing NewsRunner and RetryRunner, but what is the extra stuff in the ps output causing $11 to be the python command and not the runner option? And again, why are these two, which presumably have done nothing, seemingly the biggest. Doh? I finally noticed these are in K and the others are in M so that question is answered at least - the two that haven't done anything actually haven't grown. -- Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Pmap shows its the heap
[EMAIL PROTECTED]:in 8:08pm 64 # pmap 24167
24167:/bin/python /opt/mailman-2.1.9/bin/qrunner
--runner=IncomingRunner:5:8
08038000 64K rwx--[ stack ]
0805 940K r-x-- /usr/local/stow/Python-2.5.2/bin/python
0814A000 172K rwx-- /usr/local/stow/Python-2.5.2/bin/python
08175000 312388K rwx--[ heap ]
CF21 64K rwx--[ anon ]
--many small libs --
total318300K
Whether its a leak or not - we need to understand why the heap is growing
and put a limit on its growth to avoid exausting memory and swapping into
oblivion...
None of the lists seem too big:
[EMAIL PROTECTED]:lists 8:24pm 73 # du -sk */*pck | sort -nr | head | awk
'{print $1}'
1392
1240
1152
1096
912
720
464
168
136
112
Researching python heap alloaction
thanks
On 7/1/08 6:14 PM, Mark Sapiro [EMAIL PROTECTED] wrote:
Fletcher Cocquyt wrote:
Here is the current leaked state since the the cron 13:27 restart only 3
hours ago:
last pid: 20867; load averages: 0.53, 0.47, 0.24
16:04:15
91 processes: 90 sleeping, 1 on cpu
CPU states: 99.1% idle, 0.3% user, 0.6% kernel, 0.0% iowait, 0.0% swap
Memory: 1640M real, 77M free, 1509M swap in use, 1699M swap free
PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND
24167 mailman1 590 311M 309M sleep0:28 0.02% python
24158 mailman1 590 308M 305M sleep0:30 0.01% python
24169 mailman1 590 303M 301M sleep0:28 0.01% python
24165 mailman1 590 29M 27M sleep0:09 0.03% python
24161 mailman1 590 29M 27M sleep0:12 0.07% python
24164 mailman1 590 28M 26M sleep0:07 0.01% python
24172 mailman1 590 26M 24M sleep0:04 0.01% python
24160 mailman1 590 26M 24M sleep0:08 0.01% python
24162 mailman1 590 26M 23M sleep0:10 0.01% python
24166 mailman1 590 26M 23M sleep0:04 0.01% python
24171 mailman1 590 25M 23M sleep0:04 0.02% python
24163 mailman1 590 24M 22M sleep0:04 0.01% python
24168 mailman1 590 19M 17M sleep0:03 0.02% python
24170 mailman1 590 9516K 6884K sleep0:01 0.01% python
24159 mailman1 590 9500K 6852K sleep0:00 0.00% python
And the mapping to the runners:
[EMAIL PROTECTED]:mailman-2.1.11 4:16pm 66 # /usr/ucb/ps auxw | egrep mailman
| awk '{print $2 $11}'
24167 --runner=IncomingRunner:5:8
24165 --runner=BounceRunner:0:1
24158 --runner=IncomingRunner:7:8
24162 --runner=VirginRunner:0:1
24163 --runner=IncomingRunner:1:8
24166 --runner=IncomingRunner:0:8
24168 --runner=IncomingRunner:4:8
24169 --runner=IncomingRunner:2:8
24171 --runner=IncomingRunner:6:8
24172 --runner=IncomingRunner:3:8
24160 --runner=CommandRunner:0:1
24161 --runner=OutgoingRunner:0:1
24164 --runner=ArchRunner:0:1
24170 /bin/python
24159 /bin/python
What are these last 2? Presumably they are the missing NewsRunner and
RetryRunner, but what is the extra stuff in the ps output causing $11
to be the python command and not the runner option? And again, why are
these two, which presumably have done nothing, seemingly the biggest.
Here's some additional thought.
Are you sure there is an actual leak? Do you know that if you just let
them run, they don't reach some stable size and remain there as
opposed to growing so large that they eventually throw a MemoryError
exception and get restarted by mailmanctl.
If you allowed them to do that once, the MemoryError traceback might
provide a clue.
Caveat! I know very little about Python's memory management. Some of
what follows may be wrong.
Here's what I think - Python allocates more memory (from the OS) as
needed to import additional modules and create new objects. Imports
don't go away, but objects that are destroyed or become unreachable
(eg a file object that is closed or a message object whose only
reference gets assigned to something else) become candidates for
garbage collection and ultimately the memory allocated to them is
collected and reused (assuming no leaks). I *think* however, that no
memory is ever actually freed back to the OS. Thus, Python processes
that run for a long time can grow, but don't shrink.
Now, IncomingRunner in particular can get very large if large messages
are arriving, even if those messages are ultimately not processed very
far. Incoming runner reads the entire message into memory and then
parses it into a message object which is even bigger than the message
string. So, if someone happens to send a 100MB attachment to a list,
IncomingRunner is going to need over 200MB before it ever looks at the
message itself. This memory will later become available for other use
within that IncomingRunner instance, but I don't think it is ever
freed back to the OS.
Also, I see very little memory change between the 3 hour old snapshot
above and the 8
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
Fletcher Cocquyt wrote:
Pmap shows its the heap
[EMAIL PROTECTED]:in 8:08pm 64 # pmap 24167
24167:/bin/python /opt/mailman-2.1.9/bin/qrunner
--runner=IncomingRunner:5:8
08038000 64K rwx--[ stack ]
0805 940K r-x-- /usr/local/stow/Python-2.5.2/bin/python
0814A000 172K rwx-- /usr/local/stow/Python-2.5.2/bin/python
08175000 312388K rwx--[ heap ]
CF21 64K rwx--[ anon ]
--many small libs --
total318300K
Whether its a leak or not - we need to understand why the heap is growing
and put a limit on its growth to avoid exausting memory and swapping into
oblivion...
At this point, I don't think it's a leak.
Your runners start out at about 9.5 MB. Most of your working runners
grow to about the 20-40 MB range which I don't think is unusual for a
site with some config.pck files approaching 1.4 MB.
Only your IncomingRunners seem to grow really big, and I think that is
because you are seeing occasional, very large messages, or perhaps it
has something to do with your custom spam filtering interface.
Does your MTA limit incoming message size?
In any case, I know you're reluctant to just let it run, but I think if
you did let it run for a couple of days that the IncomingRunners
wouldn't get any bigger than the 310 +- MB that you're already seeing
after 3 hours, and the rest of the runners would remain in the 10 - 50
MB range.
I don't think you'll see a lot of paging activity of that 300+MB
because I suspect that most of the time nothing is going on in most of
that memory
None of the lists seem too big:
[EMAIL PROTECTED]:lists 8:24pm 73 # du -sk */*pck | sort -nr | head | awk
'{print $1}'
1392
1240
1152
1096
912
720
464
168
136
112
Researching python heap alloaction
You may also be interested in the FAQ article at
http://wiki.list.org/x/94A9.
--
Mark Sapiro [EMAIL PROTECTED]The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
On 7/1/08, Mark Sapiro wrote: In any case, I know you're reluctant to just let it run, but I think if you did let it run for a couple of days that the IncomingRunners wouldn't get any bigger than the 310 +- MB that you're already seeing after 3 hours, and the rest of the runners would remain in the 10 - 50 MB range. The thing I've discovered when doing detailed memory/performance analysis of Mailman queue runners in the past is that, by far, the vast amount of memory that is in use is actually shared across all the processes, so in this case you'd only take that ~310MB hit once. Some OSes make it more clear than others that this memory is being shared, and conversely some OSes appear to count this shared memory as actually belonging to multiple separate processes and end up vastly overstating the amount of real memory that is being allocated. You may also be interested in the FAQ article at http://wiki.list.org/x/94A9. It would be interesting to have all those same commands run for the system in question, to compare with the numbers in the FAQ. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
On 7/1/08, Fletcher Cocquyt wrote:
Pmap shows its the heap
[EMAIL PROTECTED]:in 8:08pm 64 # pmap 24167
24167:/bin/python /opt/mailman-2.1.9/bin/qrunner
--runner=IncomingRunner:5:8
08038000 64K rwx--[ stack ]
0805 940K r-x-- /usr/local/stow/Python-2.5.2/bin/python
0814A000 172K rwx-- /usr/local/stow/Python-2.5.2/bin/python
08175000 312388K rwx--[ heap ]
CF21 64K rwx--[ anon ]
--many small libs --
total318300K
And when I do the same thing on the mail server for python.org (which
hosts over 100 lists, including some pretty active lists with large
numbers of subscribers), on the largest queue runner we have
(ArchRunner at 41m), I see:
# pmap 1040 | sort -nr -k 2 | head
total45800K
0815f000 23244K rwx--[ anon ]
40f61000 4420K rw---[ anon ]
40a0f000 2340K rw---[ anon ]
408aa000 1300K rw---[ anon ]
40745000 1300K rw---[ anon ]
40343000 1160K r-x-- /usr/lib/i686/cmov/libcrypto.so.0.9.8
4009c000 1092K r-x-- /lib/libc-2.3.6.so
41844000 1040K rw---[ anon ]
08048000944K r-x-- /usr/local/bin/python
No heap showing up anywhere. Doing the same for our IncomingRunner, I get:
# pmap 1043 | sort -nr -k 2 | head
total23144K
0815f000 7740K rwx--[ anon ]
40b12000 1560K rw---[ anon ]
40745000 1300K rw---[ anon ]
40cb8000 1168K rw---[ anon ]
40347000 1160K r-x-- /usr/lib/i686/cmov/libcrypto.so.0.9.8
4009c000 1092K r-x-- /lib/libc-2.3.6.so
4098d000 1040K rw---[ anon ]
08048000944K r-x-- /usr/local/bin/python
4063b000936K rw---[ anon ]
Again, no heap.
None of the lists seem too big:
[EMAIL PROTECTED]:lists 8:24pm 73 # du -sk */*pck | sort -nr | head | awk
'{print $1}'
1392
1240
1152
1096
912
720
464
168
136
112
Where did you do this? In the /usr/local/mailman directory?
When I did this in /usr/local/mailman, all of the .pck files that
showed up were actually held messages in the data/ directory, not in
lists/. This would mean that they were individual messages that had
been pickled and then held for moderation, not pickles for lists.
Doing the same in /usr/local/mailman/lists, I find that one of our
smaller mailing lists (python-help, seventeen recipients) has the
largest list pickle (1044 kilobytes). We have a total of 150 lists,
and here's the current subscription count of the five biggest lists:
4075 Python-list
3305 Tutor
2600 Mailman-Users
2329 Mailman-announce
1528 Python-announce-list
Of these, python-list and tutor frequently gets between twenty to a
hundred or more messages in a day. However, here's their respective
list.pck files, using the same du -sk script from above:
904 tutor/config.pck
652 python-list/config.pck
476 mailman-users/config.pck
324 mailman-announce/config.pck
208 python-announce-list/config.pck
--
Brad Knowles [EMAIL PROTECTED]
LinkedIn Profile: http://tinyurl.com/y8kpxu
--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
On 7/1/08, Mark Sapiro wrote: In this snapshot PID USERNAME LWP PRI NICE SIZE RES STATETIMECPU COMMAND 10123 mailman1 590 314M 311M sleep1:57 0.02% python 10131 mailman1 590 310M 307M sleep1:35 0.01% python 10124 mailman1 590 309M 78M sleep0:45 0.10% python 10134 mailman1 590 307M 81M sleep1:27 0.01% python 10125 mailman1 590 307M 79M sleep0:42 0.01% python 10133 mailman1 590 44M 41M sleep0:14 0.01% python 10122 mailman1 590 34M 30M sleep0:43 0.39% python 10127 mailman1 590 31M 27M sleep0:40 0.26% python 10130 mailman1 590 30M 26M sleep0:15 0.03% python 10129 mailman1 590 28M 24M sleep0:19 0.10% python 10126 mailman1 590 28M 25M sleep1:07 0.59% python 10132 mailman1 590 27M 24M sleep1:00 0.46% python 10128 mailman1 590 27M 24M sleep0:16 0.01% python 10151 mailman1 590 9516K 3852K sleep0:05 0.01% python 10150 mailman1 590 9500K 3764K sleep0:00 0.00% python Which processes correspond to which runners. And why are the two processes that have apparently done the least the ones that have grown the most. In contrast, the mail server for python.org shows the following: top - 06:54:48 up 29 days, 9:09, 4 users, load average: 1.05, 1.08, 0.95 Tasks: 151 total, 1 running, 149 sleeping, 0 stopped, 1 zombie Cpu(s): 0.2% user, 1.1% system, 0.0% nice, 98.7% idle PID USER PR VIRT NI RES SHR S %CPUTIME+ %MEM COMMAND 1040 mailman9 42960 0 41m 12m S0 693:59.44 2.1 ArchRunner:0:1 -s 1041 mailman9 22876 0 20m 7488 S0 478:18.62 1.0 BounceRunner:0:1 1045 mailman9 20412 0 19m 10m S0 3031:12 0.9 OutgoingRunner:0: 1043 mailman9 20476 0 18m 4968 S0 127:02.62 0.9 IncomingRunner:0: 1042 mailman9 18564 0 17m 7316 S0 11:34.14 0.9 CommandRunner:0:1 1046 mailman 11 17276 0 15m 10m S1 66:32.16 0.8 VirginRunner:0:1 1044 mailman9 11568 0 9964 5184 S0 12:34.04 0.5 NewsRunner:0:1 -s And those are the only Python-related processes that show up in the first twenty lines. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Python process size grows 30x in 8 hours (memory
On 7/1/08, Fletcher Cocquyt wrote: Fletcher Cocquyt Senior Systems Administrator Information Resources and Technology (IRT) Stanford University School of Medicine BTW, in case it hasn't come through yet -- I am very sensitive to your issues. In my real life, I am currently employed as a Sr. System Administrator at the University of Texas at Austin, with about ~50,000 students and ~20,000 faculty and staff, and one of my jobs is helping out with both the mail system administration and the mailing list system administration. So, just because I post messages quoting the current statistics we're seeing on python.org, that doesn't mean I'm not sensitive to the problems you're seeing. All I'm saying is that we're not currently seeing them on python.org, so it may be a bit more difficult for us to directly answer your questions, although we'll certainly do everything we can do help. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] How can I check status of or abort a mailing in progress?
I have been hosting a mailing list of 16,000 names which has been purring along for over a year now with no problems. (I am running Mailman 2.1.5, Postfix-2.2.10, on RHES 4.0) Recently I reconfigured this list to enable personalization so my client could do a better job of processing cancellation requests from subscribers. The processing time for a mailing (from the smtp log) went from a few seconds per mailing to a few minutes, but nothing unreasonable. Heady from this success, I re-reconfigured the list to enable full personalization. My client posted his first message using this configuration Sunday night and it is still being processed (Tuesday night). The smtp log is filling with entries indicating either one or three recipients were processed. [I understand the reason for the singletons but not the triplets.] These entries occur in batches of a hundred or so and then pause for an hour or two. I have no idea how far the system has gotten in processing the entire list. Is there any way to find out? (The message already appears in the archives but there is no entry in the Mailman post log.) My client wants me to cancel the post, but I can't find any indication of how one would go about doing that. Nothing in the documentation, wiki, FAQ, and only one post on the subject on this list (but without an answer to the question). Any help would be appreciated. (Also pointing me toward any general document on the overall design and architecture of Mailman would be appreciated. The only documentation I can find is user or list-admin oriented. Not a clue about how Mailman actually gets its job done.) Thanks in advance, John Hicks -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] How can I check status of or abort a mailing in progress?
On 7/2/08, John Hicks wrote: I have no idea how far the system has gotten in processing the entire list. Is there any way to find out? (The message already appears in the archives but there is no entry in the Mailman post log.) Other than what is showing up in the Mailman smtp logs and in the postfix syslog, there's no status tool that I know of. My client wants me to cancel the post, but I can't find any indication of how one would go about doing that. Nothing in the documentation, wiki, FAQ, and only one post on the subject on this list (but without an answer to the question). It's pretty simple, actually -- stop Mailman and postfix, clean out all the affected queue messages and move them aside, then restart Mailman and postfix. How you find out which queue messages are affected will be a bit harder, but with the dumpdb program for dumping Python pickles, and the postcat command to look at postfix messages in the queue, that shouldn't be too excessively difficult. (Also pointing me toward any general document on the overall design and architecture of Mailman would be appreciated. The only documentation I can find is user or list-admin oriented. Not a clue about how Mailman actually gets its job done.) I'm not sure what you're asking for. There's plenty of FAQ entries that are specific to site admins, and there's also documentation specific to site administrators. I don't know how much more actually gets its job done you get than that. -- Brad Knowles [EMAIL PROTECTED] LinkedIn Profile: http://tinyurl.com/y8kpxu -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
