Bug#860865: sendmail: arbitrary setrlimit(1024, 1024) causes file descriptor starvation
Package: sendmail-bin
Version: 8.14.4-4+deb7u1
Severity: important
Tags: upstream
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Running Sendmail as a production mail server for front-line processing
(determining if e-mail should be accepted for further processing or not)
with a constant flow of 100msgs/s spanned over 4 servers.
At peak time, it happens that the open file limit for the process is
reached. Sendmail runs limited to 1024 file descriptors, which can be
verified with the following command :
$ cat /proc/`pgrep sendmail`/limits | grep "open file"
Max open files 1024 1024 files
File descriptor starvation causes sendmail to be unable to do name resolution
for the next SMTP relay server, either by means of DNS query, or of /etc/hosts.
This in turn causes e-mail to be deferred or bounced, and since it can not
resolve the relay host name for bouncing, this can cause messages to be
discarded after accepting them.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I tried modifying the limits by hand before launching sendmail,
by inserting a "ulimit -Sn 4096" command in /etc/default/sendmail,
expecting it to be ran during the init script.
(This is ran on a server that does not use systemd as its init system)
* What was the outcome of this action?
Investigation reveals that sendmail has hardcoded a setrlimit() call
for open files, limiting it to FD_SETSIZE (1024) no matter what.
The initial "ulimit -Sn 4096" call is overridden by sendmail itself,
and the open files limit does not change.
* What outcome did you expect instead?
I understand the limiting to FD_SETSIZE since sendmail relies on select(),
but this only takes in account mail-processing related connections,
and not any other file descriptor sendmail itself might need to open to work.
I would at the very least expect sendmail to have some leeway for other file
descriptors. (Such as running setrlimit() with more than FD_SETSIZE)
Ideally, the user should be able to set this limit by way of configuration,
or at least be able to override it via the initialization script like I tried,
since it is not intrusive to sendmail's code.
The easiest way would be to patch the resetlimits() function
(called from main.c at line 1357, defined in conf.c at line 3751)
so that it :
- Checks whether FD_SETSIZE is inferior to the current limitation before
applying it
- allocates FD_SETSIZE + N descriptors (N being a value such as 64 or 128,
though personal taste would lean towards higher values)
These limits are supposedly in place to avoid denial-of-service, but in my
situation they end up aggravating the situation.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 8.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Foreign Architectures: amd64
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages sendmail-bin depends on:
ii debconf 1.5.56
ii libc6 2.19-18+deb8u4
ii libdb5.3 5.3.28-9
ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2
ii liblockfile1 1.09-6
ii libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii libssl1.0.0 1.0.1t-1+deb8u2
ii libwrap0 7.6.q-25
ii procps 2:3.3.9-9
pn sendmail-base <none>
pn sendmail-cf <none>
sendmail-bin recommends no packages.
Versions of packages sendmail-bin suggests:
pn libsasl2-modules <none>
ii openssl 1.0.1t-1+deb8u2
pn sasl2-bin <none>
pn sendmail-doc <none>
Reply to: