sendmails works, but opens 43 file handles per email -> problem

I'm using Sendmail 8.13.8 on a CentOS 5.5 vServer (Virtuozzo).

I'm using a loop in PHP to send a lot of HTML-mails via sendmail. Each mail is a mail with individual statistics for our users, so its not mass mailing, bcc is not an option.

It all works fine, but when I take a closer look there is a problem heading our way with a high number of mails:

For each mail sendmail opens up 43 files. Sometimes these open files get closed again very fast, sometimes not.

Here is an example using the PHP-script below, it sends 20 mails in a loop:

[root]# php test-mail.php
START: number of open files: 2113
END: number of open files: 2973

This is the worst case. The number of open files (lsof | wc -l) used to send the 20 mails is 860 => 43 open files per mail.

Sometimes the files are closed very fast, so I get results like this, too:

[root]# php test-mail.php
START: number of open files: 2113
END: number of open files: 2242

This shows 129 (3 * 43) open files, so the open files for 17 send mails are already closed, for 3 mails the 129 files are still open.

In the worst case and with lots of mails our server crashes, the numfile limit of 8192 in user_beancounters is reached (our ISP won't give us more than 8192).

Sendmail DeliveryMode is background.

Could it be that sendmail tries to send lots ob mails asyncronously and uses 43 open files for each? I'm only depending on sendmail to deliver the mails, normaly I wouldn't dare to touch the sendmail config (like 'if you don't know what you're doing, don't!').

Any ideas?

BTW: It is not a problem of PHP. I verified this by sending mails via SMTP localhost to sendmail (opened 43 files per mail) and sending mails via SMTP to an ISP-relay (did not open any files per mail).

Thank you very much for reading this,
best,
Andreas

This is the code for test-mail.php:

<?php
$output = shell_exec('lsof | wc -l');
echo "START: number of open files: $output";

// HTML message
$msg = '<html><head><title>Test mail</title></head><body><p>Mailbody</p></body></html>';

// Set 'Content-type'-header
$header  = 'MIME-Version: 1.0' . "\r\n";
$header .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";

for($i=0; $i<20; $i++) {
	// send mail, this opens up 43 files for each
	mail('you@yourdomain.com', 'Testmail '.$i, $msg, $header, '-f bounce@yourdomain.com');
}

$output = shell_exec('lsof | wc -l');
echo "END: number of open files: $output";
?>

Most of those open files are shared libraries. Some are config files.
Every time you execute a command like mailx -s 'subject' user@my.com < filename
you incur the overhead of loading the shared libraries, and config files.

The beauty of shared libraries is that they are usually memory resident, shared among all processes, so you can actually run several sendmail processes concurrently, and not really impact the system more than if you ran a single instance of it.

So, I must be missing something.

try

ldd sendmail

to see what I mean.

Hi Jim,
thank you for the information.

> The beauty of shared libraries is that they are usually memory resident, shared among all processes

This is my understanding, too - otherwise lots of processes (not only sendmail) would crash every server. These are the libs used:

[root]# ldd /usr/lib/sendmail
libssl.so.6 => /lib64/libssl.so.6 (0x00002ab174bca000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002ab174e16000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00002ab175167000)
libwrap.so.0 => /lib64/libwrap.so.0 (0x00002ab175380000)
libhesiod.so.0 => /usr/lib64/libhesiod.so.0 (0x00002ab175589000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ab17578d000)
libdb-4.3.so => /lib64/libdb-4.3.so (0x00002ab1759c6000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002ab175cbc000)
libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002ab175ed5000)
liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002ab176110000)
libc.so.6 => /lib64/libc.so.6 (0x00002ab17631e000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00002ab176675000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002ab17688b000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002ab176ab9000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002ab176d4e000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002ab176f51000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ab177176000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00002ab17737a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ab17758f000)
/lib64/ld-linux-x86-64.so.2 (0x00002ab17465b000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002ab1777aa000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002ab1779b2000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ab177bb5000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x00002ab177dcd000)

Sendmail is running:

root 28089 0.0 0.0 62812 2320 ? Ss Dec10 0:33 sendmail: accepting connections
smmsp 28097 0.0 0.0 57692 1780 ? Ss Dec10 0:00 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue

Do you think setting the Sendmail DeliveryMode to 'interactice' would help? I read the sendmail documentation, but I'm still not sure what risks it would involve.

Best,
Andreas