Re: router memory

[Ken Lalonde <ken@uunet.ca>]

Here's the strategy I'm using with our version of zmailer:

First, I admit defeat in the memory-leak wars.
Any long-running program with heavy allocation demands runs
the risk of bloating, possibly through no fault of its own.
Limiting the program run time reduces the risk at little cost.

Second, past experience shows that some mechanism is needed to deal
with router death, and to limit the damage.  It shouldn't happen,
but it does.

Here's the general idea:
At start time, the main router process forks $NROUTER children.
The parent process just monitors the children; it doesn't process any
messages itself.  Each child processes $NMESSAGES router files
(currently 20), then exits.  The parent forks new children as needed.
If a child is killed by a signal other than SIGTERM, the parent moves
the message file the dead process was processing to the directory
postman/lethal.  (A cron script checks for such files, and notifies the
postmaster.) Since in-progress router message files have the router
process PID as part of the file name, this is easy to do.

On memory exhaustion, emalloc() just complains and abort()s,
on the assumption that the parent router will clean up.

This scheme has been working well for over a year.

Ken Lalonde
UUNET Canada