Mailman 3 June 2000 - Mailman-Developers

logs
by Ricardo Kustner 01 Jun '00

01 Jun '00

Hi, I was just looking into my logs directory and I noticed a 10mb bounce log file... maybe we should consider using something like log rotating? ie log.0, log.1.gz, log.2.gz etc... or should this be left as a task for the admin and/or distibution maintainer? another option would be to set a maximum log size Ricardo. --

3 2

Re: [Mailman-Developers] logs
by J C Lawrence 01 Jun '00

01 Jun '00

On Thu, 1 Jun 2000 12:08:03 +0200 Ricardo Kustner <ricardo(a)rixhq.nu> wrote: > I was just looking into my logs directory and I noticed a 10mb > bounce log file... maybe we should consider using something like > log rotating? ie log.0, log.1.gz, log.2.gz etc... or should this > be left as a task for the admin and/or distibution maintainer? This should be left as a task for the Admin/packager, tho it should be noted in the README. Depending on the list environment, sometimes that log data can also be legal data... -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re-tries for failed SMTPDirect deliveries
by Barry A. Warsaw 01 Jun '00

01 Jun '00

Last night, I added some code to queue messages that fail delivery when using SMTPDirect. What happens is this: If a message either totally fails delivery (e.g. the smtp socket connect fails) or partial delivery fails for some, but not all, recipients, then the message is stored on the file system for a re-try later. For every failed message, two files are created. The base name of these files is the SHA hexdigest dump of the message text. This should be nearly guaranteed unique. A new directory contains these files, called `qfiles'. The first file created is the complete plain text of the failed message. The second file is a marshal of useful information related to the failed delivery. This contains the listname and the failed recip list along with a few other moderately useful bits of info. There's a new cron script called `qrunner' which cruise the files in qfiles. It claims a lock (to prevent multiple qrunner processes) and then goes through each file it finds, attempting redelivery. If there are any problems reading a qfile file, it skips it for next time (assumes it's a transient problem with the file, but logs a message). When qrunner notices that the message has been handed off the the smtp daemon for all outstanding recipients, it deletes the two message files. I've moderately tested this stuff with total delivery failure by shutting off my smtp daemon, attempting some deliveries, turning it back on and running qrunner. I don't have the time right now to test partial delivery failures, but I still claim that without DSN support, these will be unlikely. Hopefully some of you can help look at this. I'm about to check all this stuff in. Let me know what you think. -Barry

3 9

pipermail/hypermail mbox-archive
by Thomas Wouters 01 Jun '00

01 Jun '00

There was a short discussion a month or so ago about the hyperarch 'mbox' archives having the wrong kind of date in the 'From ' lines... 'unixfrom' lines should have a very specific dateformat, namely that which 'time.ctime' returns. The following patch fixes Archiver/HyperArch.py. However, I'm not entirely sure if it will work correctly in other locales... can anyone test that, and propose a locale-independant way of producing this format ? Grtz, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 3

CVS: mailman/Mailman ListAdmin.py,1.33,1.34
by Fil 01 Jun '00

01 Jun '00

It works great! Two cents= * in order to still have a responsive server, you need qrunner to be activated every minute or every other minute, not just every half hour like it is now (usually). * nothing is logged into /logs/* when a message is approved. Very stressfull for the mailman-master trying to watch if it works. S/he has to think to look at qfiles/ to see if the message was correctly processed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Date: Tue, 30 May 2000 22:36:43 -0700 From: Barry Warsaw <bwarsaw(a)slayer.i.sourceforge.net> To: mailman-checkins(a)python.org Subject: [Mailman-checkins] CVS: mailman/Mailman ListAdmin.py,1.33,1.34 Update of /cvsroot/mailman/mailman/Mailman In directory slayer.i.sourceforge.net:/tmp/cvs-serv13283 Modified Files: ListAdmin.py Log Message: __handlepost(): Instead of trying to deliver approved messages immediately with DeliverToList(), enqueue the message for later delivery by qrunner. This vastly improves the responsiveness of the web interface for huge lists.

3 5

more problems with lockfiles..
by Matt Davis 01 Jun '00

01 Jun '00

hate to bring this up again.. but i tried the followin.. 1. current cvs code + patch Harald fixed up 2. current cvs code - patch Harald fixed up Both give the same problem I was having before.. Here's the rundown.. 1. I goto the 'view other subscriptions' page with correct password an NO lock file (no lock/davis.lock). 2. the error comes right up with the following traceback. Traceback (innermost last): File "/home/mailman/scripts/driver", line 89, in run_main main() File "/home/mailman/Mailman/Cgi/handle_opts.py", line 80, in main mlist.Save() File "/home/mailman/Mailman/MailList.py", line 867, in Save self.__lock.refresh() File "/home/mailman/Mailman/LockFile.py", line 204, in refresh raise NotLockedError NotLockedError: & << -- start lock log -- >> Jun 01 00:03:58 2000 (6084) davis.lock laying claim Jun 01 00:03:58 2000 (6084) davis.lock got the lock Jun 01 00:03:58 2000 (6084) davis.lock laying claim Jun 01 00:03:58 2000 (6084) davis.lock already locked << -- stop lock log -- >> 3. Well.. I hit refresh and there is now a davis.lock file. And it waits (probably until Jun 01 00:04:24 2000 (6095) davis.lock laying claim Jun 01 00:04:24 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:04:24 2000 (6095) davis.lock waiting for claim Jun 01 00:04:24 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:04:25 2000 (6095) davis.lock unexpected linkcount <> 2: 1 <snip> (you get the idea..) Jun 01 00:04:51 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:04:53 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:06:05 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:06:05 2000 (6095) davis.lock waiting for claim Jun 01 00:06:06 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:06:06 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:06:08 2000 (6095) davis.lock unexpected linkcount <> 2: 1 Jun 01 00:06:08 2000 (6095) davis.lock lifetime has expired, breaking Jun 01 00:06:08 2000 (6095) davis.lock got the lock Jun 01 00:06:08 2000 (6095) davis.lock laying claim Jun 01 00:06:08 2000 (6095) davis.lock already locked The other weird thing is i'm using the same Lockfile.py as the one you edited. at least diff didnt see any differences. PLUS i can view other subscriptions on python.org. Is python.org using current CVS code from sourceforge? PS. I'm willin to be a guinie pig again :) -- Matt Davis - ICQ# 934680 http://dogpound.vnet.net/ The severity of the itch is proportional to the reach.

2 3

latest CVS; multiple message approval
by Mentor Cana 01 Jun '00

01 Jun '00

There seems to be a problem when approving multiple messages in the latest CVS (this evening). When approving multiple messages at least one of them will disappear. logs/vette shows the messages as approved, however the messages never makes it to the archives and it does not get distributed. I tried this with 2 and three messages waiting for approval. Hope this helps to resolve a possible problem. thanks, mentor

2 1

approved messages in 2.0beta3 not archived
by Mentor Cana 01 Jun '00

01 Jun '00

Hello, Some testing with 2.0beta3 revealed that the approved message are not being archived properly. Actually, the messages get into the list.mbox file but they are missing the "From " line and therefore do not show on the archive page. later, Mentor

3 2