Mailman 3 September 2000 - Mailman-Developers

unsusbcribe
by Irma Sheen Sept. 1, 2000

Sept. 1, 2000

1 0

"too many files" problem.
by Chuq Von Rospach Sept. 1, 2000

Sept. 1, 2000

I've done more investigating, and I've been able to prove that it was a system table filling up, so it's definitely *not* a bug in mailman... -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

1 0

Fwd: Cron <mailman@plaidworks> /usr/bin/python -S /home/mailman/cron/mailpasswds
by Chuq Von Rospach Sept. 1, 2000

Sept. 1, 2000

Ran into this with the password-sending stuff. As far as I can tell, I ran out of file descriptors on a system wide basis as it dealt with the deluge of returning bounces and vacation bots (it's Labor day! everyone's gone!) -- but Mailman needs to deal with this error gracefully, not bomb. Recommendation: if you run out trying to send a password reminder, go to sleep for a period of time to let the system settle. If you get this trying to suck in returned mail, send a DEFERRED error back to the MTA and try it again later. Also, Barry, you probably ought to double-check that you aren't leaking file descriptors in your password processing. I didn't see this in beta 4 on the same system, so it might be a new bug in b5. I'm looking to increase my file table limit, but that is working around the system, not the problem. --- begin forwarded text Date: Fri, 1 Sep 2000 05:31:14 -0700 From: root (Cron Daemon) To: mailman Subject: Cron <mailman@plaidworks> /usr/bin/python -S /home/mailman/cron/mailpasswds X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/home/mailman> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=mailman> Traceback (innermost last): File "/home/mailman/cron/mailpasswds", line 153, in ? File "/home/mailman/cron/mailpasswds", line 148, in main File "/home/mailman/cron/mailpasswds", line 84, in mail_passwords File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 181, in DeliverToUser File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 152, in DeliverToList File "/home/mailman/Mailman/Message.py", line 176, in Enqueue File "/home/mailman/Mailman/Utils.py", line 578, in open_ex IOError: [Errno 23] Too many open files in system: '/home/mailman/qfiles/2927df48866c7f7e7fb0221ea2168296955d66b8.db' --- end forwarded text -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

1 0

Automatic list alises for QMail
by Sean Reifschneider Sept. 1, 2000

Sept. 1, 2000

I'd like comments on the following program. The idea is that for QMail, new lists will automaticly be detected and there will be no need to do anything beyond "newlist". Goodbye having to translate the sendmail alias entries into .qmail files. Goodbye having to much with aliases ever again (as far as the list is concerned). Comments? Sean -- I like to be different, so I built a lowercase a-frame house. -- Sean Reifschneider, 2000 Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

1 0

Mailman and virtual domains
by Sean Reifschneider Sept. 1, 2000

Sept. 1, 2000

Greetings. Now that I've got a spare box I can install the new mailman on, without having to worry about freaking out something that relies on the heavily hacked older copy of Mailman, i've finally started mucking around with it again. Looks good, though I do see that my QMail auto-detect patch didn't go in (for changing the format of the "aliases" list in newlist). ;-) So, I've been thinking some, and since the box that this is running on is going to be dealing with a bunch of virtual domains, the thinking has been about virtual domains. It would be nice if one could have lists with the same name in two different domains, handled by one instance of mailman. Perhaps instead of passing the wrapper "name" you'd pass it "name@domain"? Then instead of having "lists/name" the directory structure would be "lists/domain/name". Perhaps there would be a "lists/Default" that would hold all mailing lists that had no domain when passed to the wrapper (for backwards compatibility)? The only other thing I can think that it would have to hit is the archive code -- same sort of thing "archives/public/domain/name". Are there any other better approaches that could possibly be taken? Maybe now would be the time to split it up some more so that you'd have something like "lists/domain/first two letters of name/name" for anyone who wants to run more than a thousand lists per box? Sean -- Give me immortality or give me death! Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

1 0