Re: header corruption -- solved

[Matti Aarnio <mea@nic.funet.fi>]

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,
> --J.

-- 
/Matti Aarnio	<mea@nic.funet.fi>