[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: header corruption -- solved
On Tue, Nov 02, 1999 at 06:49:25AM +0100, Jan Rychter wrote:
> The header corruption problem I was seeing was caused by installing a
> new version of zmailer over an old one. I did delete the router.fc file,
> but apparently the cf/ files are not overwritten when one does "make
> install" and this can result in strange behavior.
Indeed. Something better must be implemented, but what ?
Localized/customized scripts should not be carelessly
overwritten, but just avoiding that part is causing the
problem you are complaining about.
The "INSTALL" document does mention this detail in passing,
but does not make it very clear -- thus it is easy to miss..
> I am a bit worried by zero interest from developers. The issue was
> serious, corrupted headers and lost E-mails. It was my error, I know,
> but I expected someone would at least take interest... I got no answers
> to the two emails I sent to the list, not even requests to submit
> precise details or debug the problem.
What can I say, "sorry" ?
Lots of people are calling for my time, and after few hundred
interrupts I tend to forget earlier topics.
Getting personal reminders of open issues could help me to
rescedule things. (I definitely should get around to HTMLize
zmailer mail-log with some status editing HTML weirdo system
allowing me to track open questions -- sort of trouble-ticket
system, but also listlog..)
> Anyway, I've reinstalled most of $MAILVAR and everything works fine now.
> By the way: the scheduler process is fairly large (2.4MB on my laptop)
> and does not get swapped out (RSS is 2340kB). It seems the scheduler
> sometimes walks over its pages and touches them all. For a large server
> this does not matter, but for smaller machines one would prefer a
> smaller process that swaps out unused pages. Is anybody working on that?
Yes, a bit sad part that. Denser memory layout would be
usefull, but *memory compaction* isn't quite so simple goal
(long time running system should compact its memory usages
when it no longer has 10 000 + messages in the queue..)
Binary size at my intel box is about 85 kB; a freshly started
server without any work seems to be VSZ=984 kB, RSS=448 kB
of which libc is - don't know how much, guess: 250 kB
Internal algorithms should be reworked quite radically for
that goal -- and still propably qmail's queue is densest.
If I remember correctly, qmail has about 12 bytes per queued
message (or was it per recipient ?)
Anyway, current system is full of doubly-linked lists running
in 3 or 4 dimensions (or thereabouts). Most space is still
spent in recipient control, and status data.
(History-status could be stored into the spoolfile; and only
keeping some flag telling 'temp' or 'final' status report
is stored at offset nn)
(mailq program, or mailq part of the scheduler, would need to
scan the files to find those entries..)
> best regards,
/Matti Aarnio <email@example.com>