Re: exim/cron causes process pollution? Can't fork -> reboot
You can manually limit the number of smail processes and the number of
parallel deliveries per process in the config file. If someone dumps a
TON of mail onto your system for delivery ( a mailing list, for example
with many destinations per message) exim can attempt to start more
delivery processes than Linux 2.0.X can handle.
I have a server that gets outbound listserve traffic dumped on it from
UUCP sites. I had to add the following to the config file:
deliver_load_max = 6
queue_only_load = 8
remote_max_parallel = 6
queue_run_max = 5
WHat this does is limit each Exim process to only 6 simultanious
deliveries. It also limits the main daemon from spawning a max of 5
sub-processes. It also kills queue runners with at a max system load of 6
and will queue messages only, no delivery attempts, at a load level of 8.
Exim does not have this problem with Solaris and I think Linus might have
raised the process and file limitations in 2.1 because he was aware of the
problem back in April.
On 22 Oct 1998, Hannu Koivisto wrote:
> Greetings,
>
> Since I replaced smail with exim (2.04-3) last Saturday or so I
> have had to boot the machine two or three times because no new
> processes can't have been started. "vfork: resource temporarily
> unavailable" is what my shell (zsh) says. If, with echo `<
> file`, I examine the contents of /proc filesystem, I see _many_
> cron processes. Too many, it seems. I don't think the process
> count is hitting kernel's default limit of 512 processes (IIRC).
>
> This booting is rather unpleasant as the machine is our router,
> {DNS, www proxy, mysql, samba, nfs, canna, skk, apache, ppp,
> print, my emacs :)} server so if anyone has had similar
> experiences, I'd like to know ASAP. I'm not sure if switching to
> exim is the actual cause -- I did update several packages about
> day or two before switched to exim, but the first time I saw
> this happen was pretty immediately after this switch.
>
> FWIW, kernel is 2.1.117ac3/x86.
>
> Good ideas about how to trace the cause of the problem are also
> appreciated. Logs haven't revealed anything relevant.
>
> Thanks in advance,
> //Hannu
>
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>
>
>
George Bonser
The Linux "We're never going out of business" sale at an FTP site near you!
Reply to: