OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: classes per domain, too many open files

From: Noel Jones (njonesmegan.vbhcs.org)
Date: Fri Aug 01 2008 - 10:10:45 CDT


Furs wrote:
> Folks,
>
> I need a sender access per domain.
>
> After reading postfix documentation i decided to use classes,
> in smtpd_recipient_restriction there is a new restriction.
> This restriction tells postfix what class to use depending
> on domain recipient. Every class has its own whitelist,
> blacklist.
>
> Problem is there are too many classes. We have more than 1200 domains,
> so we use more than 1200 classes, it seems that postfix can't open them
>
> When we start postfix all is fine, but when we recieve a new mail postfix
> log an error message:
>
> "fatal: open database /etc/postfix/recipient-access/domains/domainXYZ.db:
> Too many open files"
>
> Somebody can tell how to avoid that.

Wow, what a maintenance nightmare!

Postfix needs to open a file descriptor for all those lookup
tables you have defined. An excerpt from the INSTALL file:

------
... the number of file descriptors per process is limited by
the value of the FD_SETSIZE macro. If you expect to run more
than 1000 mail delivery processes, you may need to override
the definition of the FD_SETSIZE macro to make select() work
correctly:

     % make makefiles CCARGS=-DFD_SETSIZE=2048

Warning: the above has no effect on some Linux versions.
Apparently, on these systems the FD_SETSIZE value can be
changed only by using undocumented interfaces. Currently, that
means including <bits/types.h> directly (which is not allowed)
and overriding the __FD_SETSIZE macro. Beware, undocumented
interfaces can change at any time and without warning.

But wait, there is more: none of this will work unless the
operating system is configured to handle thousands of
connections. See the TUNING_README guide for examples of how
to increase the number of open sockets or files.

------

I think you'll be better off if you move this to an external
policy server. www.policyd.org is a good place to start.

--
Noel Jones