OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: 451 queue errors due to max open files on

Re: 451 queue errors due to max open files on Linux


Subject: Re: 451 queue errors due to max open files on Linux
From: Rich Graves (rcgravesbrandeis.edu)
Date: Fri Jan 21 2000 - 18:09:25 CST


On Fri, 21 Jan 2000, Wietse Venema wrote:

> Rich Graves:
> > Jan 20 17:49:07 moe postfix/smtpd[19436]: fatal: accept connection: Too
> > many open files in system
>
> Your kernel can't handle more open files. Beef up your kernel. Or
> run an O/S that scales better.

Of course; the Linux-specific way of doing that without rebooting being:

> > * Quadruple the kernel open file limit (echo 16384 > /proc/sys/fs/file-max)

I'm doing fine; I was just reporting this to help other people. It looks
like the same general issue bites AIX.

I've since raised the smtpd concurrency back up to 100. We've handled a few
large-scale spams today without incident.

The BSDs tend to be distributed with higher default limits, but this
(alone) doesn't mean Linux scales worse. Open files are just a sysctl away.
On this particular server I have a (perceived) requirement for fast
hardware RAID. Getting that on *BSD or a commercial UNIX would have cost a
lot more.

> > What exactly does "throttling" mean? It didn't stop accepting connections.
>
> If a service fails consistently, the Postfix master will stop
> spawning new processes for that service for 60 seconds, in order
> to allow the host to recover from overload.
>
> This is so much nicer than running the system into the ground.
>
> Meanwhile, the master can't close the service socket because other
> servers still have it open, so the kernel still accepts connections
> for the service. Nothing I can do about that.

OK, that's what I was unclear about. Sendmail's architecture is such that
it does end up killing the socket.

P.S. for that off-topic IMAP/SSL thread:

 http://fy.chalmers.se/~appro/ssl_inetd.html

Performs better than sslwrap and friends.

-- 
Rich Graves <rcgravesbrandeis.edu>
UNet Systems Administrator



This archive was generated by hypermail 2b27 : Fri Jan 21 2000 - 18:21:25 CST