arch eats up all my memory and hangs when processing a message that has a 12MB attachment (my machine has 1G of memory)
When mailman creates an archive mbox file, it puts a empty line at the beginning. This is annoying as it prevents me from doing mutt -f list.mbox
It would be really cool if the admin web interface would let me click on a link to edit the held message (headers and body) before I approve it (in a textarea)
Thanks, Marc
Microsoft is to software what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ (friendly to non IE browsers) Finger marc_f@merlins.org for PGP key and other contact information
On Tue, Apr 25, 2000 at 11:14:10AM -0700, Marc Merlin wrote:
- arch eats up all my memory and hangs when processing a message that has a 12MB attachment (my machine has 1G of memory)
Howmany messages are in the archive mailbox ? What kind of machine is it ? I've recently arch'ed an old mail archive into a new list, where the old archive (my own private archive of the list, which has existed for over 5 years) contained close to 9000 messages. No overly large attachements, though, but the machine none the less handled it pretty well.
arch *does* load the entire mailbox into memory, though. How large is the mailbox in total ?
[ Have no real answer to the other questions, so sorry for not answering ]
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On mar, avr 25, 2000 at 10:28:48 +0200, Thomas Wouters wrote:
On Tue, Apr 25, 2000 at 11:14:10AM -0700, Marc Merlin wrote:
- arch eats up all my memory and hangs when processing a message that has a 12MB attachment (my machine has 1G of memory)
Howmany messages are in the archive mailbox ? What kind of machine is it ?
2675 messages, not that many. I removed 3 messages with large attachments, re-ran arch and it ran just fine. Before, when it reached the 12MB attachement, it ate more than 400MB
I am moving mailman to an up to date machine, but in the meantime: oxygen:~# rpm -qf /usr/bin/python python-1.5.1-5
Maybe a newer python will help.
arch *does* load the entire mailbox into memory, though. How large is the mailbox in total ?
Not that big, 25MB.
[ Have no real answer to the other questions, so sorry for not answering ]
Eh, one answer is already good :-)
Marc
Microsoft is to software what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ (friendly to non IE browsers) Finger marc_f@merlins.org for PGP key and other contact information
"MM" == Marc Merlin <marc_news@valinux.com> writes:
MM> 2675 messages, not that many. I removed 3 messages with large
MM> attachments, re-ran arch and it ran just fine. Before, when
MM> it reached the 12MB attachement, it ate more than 400MB
MM> I am moving mailman to an up to date machine, but in the
MM> meantime: oxygen:~# rpm -qf /usr/bin/python python-1.5.1-5
MM> Maybe a newer python will help.Probably not.
Pipermail is currently the most neglected aspect of Mailman. I'd love for somebody to adopt it and expend some serious energy on it. In the meantime, for anybody doing serious archiving, including w/ lots of attachments, you probably want to investigate an external archiver.
-Barry
On Tue, Apr 25, 2000 at 06:58:57PM -0400, Barry A. Warsaw wrote:
MM> Maybe a newer python will help.
Probably not.
Pipermail is currently the most neglected aspect of Mailman. I'd love for somebody to adopt it and expend some serious energy on it.
Actually, I'm more or less doing that. I'm currently grokking pipermail/HyperArch, and will probably rewrite HyperArch in pipermails' image, but without subclassing it (because HyperArch ends up masking most pipermail things, and I dont want to rewrite them *both*) unless pipermail is being actively maintained/developped outside of Mailman, or someone else knows a better python-based archiver/thingy ?
Anyway, the attachements issue & the newline at the top of each list.mbox is on my 'todo' list ;)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Wed, 26 Apr 2000, Thomas Wouters wrote:
Actually, I'm more or less doing that. I'm currently grokking pipermail/HyperArch, and will probably rewrite HyperArch in pipermails' image, but without subclassing it (because HyperArch ends up masking most pipermail things, and I dont want to rewrite them *both*) unless pipermail is being actively maintained/developped outside of Mailman, or someone else knows a better python-based archiver/thingy ?
I think, the pipermail should be definietly removed from mailman. It is mutch better to use some external archiver. You will have match more stable mailman without pipermail.
When someone will corect my poor english, I can write mailman-archiving howto for mailman-MHonArc cooperation.
cheers dan
--
________________________________________
DDDDDD
DD DD Dan Ohnesorg, supervisor on POWER
DD OOOO Dan@feld.cvut.cz
DD OODDOO Dep. of Power Engineering
DDDDDD OO CTU FEL Prague, Bohemia
OO OO work: +420 2 24352785;+420 2 24972109
OOOO home: +420 311 679679;+420 311 679311
________________________________________
Nekdy je rozumne o krok ustoupit, aby se prodlouzil rozbeh.
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> Actually, I'm more or less doing that. I'm currently grokking
TW> pipermail/HyperArch, and will probably rewrite HyperArch in
TW> pipermails' image, but without subclassing it (because
TW> HyperArch ends up masking most pipermail things, and I dont
TW> want to rewrite them *both*) unless pipermail is being
TW> actively maintained/developped outside of Mailman, or someone
TW> else knows a better python-based archiver/thingy ?I don't think anybody is actively maintaining Pipermail anymore, so you essentially have free rein here. It has to be Python, and it should integrate cleanly with the existing framework, but it would be okay if it uses the external archiver interface.
TW> Anyway, the attachements issue & the newline at the top of
TW> each list.mbox is on my 'todo' list ;)Excellent! Thanks. -Barry
participants (5)
-
Barry A. Warsaw -
bwarsaw＠cnri.reston.va.us
-
Dan Ohnesorg -
Marc Merlin -
Thomas Wouters