Mailman/Defaults.py is not updated?
Bug in Mailman version 2.1a4+
We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks!
Traceback:
Traceback (most recent call last): File "/home/mailman/scripts/driver", line 86, in run_main main() File "/home/mailman/Mailman/Cgi/admindb.py", line 218, in main show_helds_overview(mlist, form) File "/home/mailman/Mailman/Cgi/admindb.py", line 390, in show_helds_overview (mm_cfg.ACCEPT, mm_cfg.HOLD, mm_cfg.REJECT, mm_cfg.DISCARD), AttributeError: 'Mailman.mm_cfg' module has no attribute 'ACCEPT'
-- Fil
"F" == Fil <fil@rezo.net> writes:
F> Bug in Mailman version 2.1a4+
F> We're sorry, we hit a bug!
F> If you would like to help us identify the problem, please email
F> a copy of this page to the webmaster for this site with a
F> description of what happened. Thanks!
F> Traceback:Did you run "config.status ; make install" ?
Any time Defaults.py.in changes (or any autoconf substituted file, like the ones in bin/) you need to re-run config.status before make install, so that they get re-generated.
Once in a while you'll have to re-run configure too, if, say I add a new script to bin/, or for any other changes to configure{,.in}.
-Barry
I'm doing my first big mailing with Mailman/Exim to deliver effector for the Electronic Frontier Foundation. The list is about 20,000 names.
Anyhow - started out moving right along, maybe too well - saturated the T1 pretty quick and the system slowed down. But the email logs were really going fast. This went on for about 45 minutes.
During this time I saw a number of errors. Messages indicating the I had too many files open (running tail on the exim logs). A few messages that looked like something couldn't open something.db or something like that.
Then .....
The delivery slowed down as it it were done. System load dropped back to low normal levels. This lasted a while - then things started back up again really delivering messages. These deliveries come in spurts.
Anyhow - even though Exim is delivering other email. Messages sent to mailman are getting "stuck". It's as if nothing in mailman is working. I see messages being sent to mailman. But mailman isn't responding. I don't know if something is holding these messages and this is waiting in some queue - or if Mailman has crashed and is eating messages - or someing is corrupt or locked or overloaded or what.
Anyhow - I'd like some general feedback on what might be happening. The newsletter contains an important story about Norway inditing Jon Johansen criminally. He's the guy who wrote the DVD code.
Anyhow - the future of the planet is at stake here - so I'd like to know this is going to work and what I need to do to fine tune the system.
Marc Perkel /root EFF
"MP" == Marc Perkel <marc@perkel.com> writes:
MP> I'm doing my first big mailing with Mailman/Exim to deliver
MP> effector for the Electronic Frontier Foundation. The list is
MP> about 20,000 names.A good cause, for sure.
MP> During this time I saw a number of errors. Messages indicating
MP> the I had too many files open (running tail on the exim
MP> logs). A few messages that looked like something couldn't open
MP> something.db or something like that.Two things are critical before we can move forward: we need to know what versions of the various bits of software you're running (and that includes OS, Python, Mailman, and Exim), and we need to see those tracebacks. Feel free to send along excerpts from logs/error and any Exim syslog entries that are relevant.
-Barry
I'm running Redhat 7.2 I'm running the 2.4.17 kernel. Python is 1.5.2. Mailman 2.0.8 and exim 3.34.
Actually the problem is lack of logs. Mailman appears to be frozen with python tasks backing up as if the mailman tasks are locking up. I'm sure it's also processing a lot of bounced email.
Could it be running into a task limit - with just being overloaded? Is there something to check the integrity of the databases?
Two things are critical before we can move forward: we need to know what versions of the various bits of software you're running (and that includes OS, Python, Mailman, and Exim), and we need to see those tracebacks. Feel free to send along excerpts from logs/error and any Exim syslog entries that are relevant.
-Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
"MP" == Marc Perkel <marc@perkel.com> writes:
MP> Actually the problem is lack of logs.Is there nothing useful in errors/log? If not, it definitely ain't a Mailman problem.
MP> Mailman appears to be frozen with python tasks backing up as
MP> if the mailman tasks are locking up. I'm sure it's also
MP> processing a lot of bounced email.Well, you can double check and see if there are any stale lock files in the locks directory. If you're exhausting your system resources as Chuq points out, and your Python processes are either hanging, thrashing with other processes, or just getting waxed by your kernel, the processes holding the locks will fail hard, leaving stale locks around.
MP> Could it be running into a task limit - with just being
MP> overloaded? Is there something to check the integrity of the
MP> databases?See Chuq's excellent post. Others in more favorable timezones are going to have to take it from here tonight, I'm beat. But you can make sure your list config.db files are still good by using bin/dumpdb or bin/config_list. Use --help to get synopsis.
-Barry
On 1/10/02 10:30 PM, "Marc Perkel" <marc@perkel.com> wrote:
Python is 1.5.2.
That version's known to have some glitches.
Actually the problem is lack of logs. Mailman appears to be frozen with python tasks backing up as if the mailman tasks are locking up. I'm sure it's also processing a lot of bounced email.
You filled up the kernel file table. Anything that writes to a file might be hosed because of that. Barry, how careful were you to verify opens succeeded, and what do you do if they fail? This might have been a stress test for your error coding.... (grin)
Could it be running into a task limit - with just being overloaded?
You're not just overloaded. Once your file table started overflowing, the system is in an unknown and inconsistent state, and the only way to recover semi-gracefully is a reboot, and then making sure THAT never happens again.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> Python is 1.5.2.
CVR> That version's known to have some glitches.Good point. Python 2.1.1 should be better. (And Python 2.1.2 release candidate just went out tonight, but I don't think Mailman users need freak out about upgrading).
>> Actually the problem is lack of logs. Mailman appears to be
>> frozen with python tasks backing up as if the mailman tasks are
>> locking up. I'm sure it's also processing a lot of bounced
>> email.
CVR> You filled up the kernel file table. Anything that writes to
CVR> a file might be hosed because of that. Barry, how careful
CVR> were you to verify opens succeeded, and what do you do if
CVR> they fail? This might have been a stress test for your error
CVR> coding.... (grin)I've been very careful with the critical parts, i.e. saving a config.db file. MM uses a write-tmp-file-and-atomically-rename scheme so if anything fails, you're guaranteed to have at least a good backup file, modulo low level problems no app can defend against.
config.db files can get corrupted, but if you've got corrupt config.db and config.db.bak files, you got more serious problems with your system.
-Barry
On Fri, 11 Jan 2002 01:21:36 -0500 Barry A Warsaw <barry@zope.com> wrote:
Two things are critical before we can move forward: we need to know what versions of the various bits of software you're running (and that includes OS, Python, Mailman, and Exim), and we need to see those tracebacks. Feel free to send along excerpts from logs/error and any Exim syslog entries that are relevant.
Uhh, Barry, until he handles his file handle exhaustion problem tracebacks aren't going to do anyone any good. Once that starts happening you're in a realm of "the kernel is doing Bad Things to my processes and probably isn't telling me!" Get the file handle exhaustion handled first, _THEN_ see if we still get any tracebacks. If so, they have a chance of containing data that might be useful. Until then, well, we just have a system that's really really sick.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On 1/10/02 10:08 PM, "Marc Perkel" <marc@perkel.com> wrote:
Anyhow - started out moving right along, maybe too well - saturated the T1 pretty quick and the system slowed down.
That's not good. IT's not a mailman problem, but it's not good. You need to tune your MTA to slow it down down so it doesn't overload the network. Once it does, the different processes/threads start fighting each other for network, and you'll see things go to heck. What I normally do is see what it takes to saturate my network, and then tune the mailer to stop about 10% shy of that.
During this time I saw a number of errors. Messages indicating the I had too many files open (running tail on the exim logs). A few messages that looked like something couldn't open something.db or something like that.
That is really, really, really bad. That's a kernel problem: you've filled up the kernel tables handling open files, so any future attempt to open a file plain old fails. Once that starts happening, if you're LUCKY, processes fail gracefully and go away, but in many cases, that doesn't happen. At this point, you're pretty hosed.
You need to see how many open files your system is configured to allow, and (a) slow down your MTA so it doesn't blow away your kernel tables, but also (b) have your kernel tuned to increase the number available.
The delivery slowed down as it it were done. System load dropped back to low normal levels.
That's actually fairly normal -- as the delivery takes up more resource, the mailman side tends to slow down. What you're likely seeing is competition for disk I/O, and your disk(s) are likely saturated. That's a whole 'nuther tuning discussion, but it's simply performance, not "it broke" bad.
Anyhow - even though Exim is delivering other email. Messages sent to mailman are getting "stuck".
Not surprising, if the file table overflowed in the kernel. First, reboot. Then, work at getting exim tuned down, it's overloading the system under load and the system is, well, barfing.
participants (5)
-
barry＠zope.com -
Chuq Von Rospach -
Fil -
J C Lawrence -
Marc Perkel