Comment 0 for bug 1649700

Sendmail 8.15.2 seems to have a file descriptor bug/handling problem, which is exposed when the ldap_routing feature is enabled.

I'm not certain I understand what you mean by "source package", but I assume what you're looking for is the 'sendmail' package.

Distro: Ubuntu 16.04.1 LTS

Package version: apt-cache policy sendmail
sendmail:
  Installed: 8.15.2-3
  Candidate: 8.15.2-3
  Version table:
 *** 8.15.2-3 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu xenial/universe i386 Packages
        100 /var/lib/dpkg/status

I expect e-mail received from a remote system to be processed and accepted by the local sendmail process.

What happens is that the sendmail process hangs and never completes processing the e-mail message, so it does not get delivered.

The configuration: When I add FEATURE(`ldap_routing', ...) to my sendmail.mc file and generate a new sendmail.cf file for sendmail to use, sendmail stops processing e-mail messages for delivery.

Background: I initially developed my mc/cf files with ldap_routing on Ubuntu 14.04 systems. I had no problems with sendmail delivery problems when I took the .cf file from my Ubuntu 14.04 system and used it under Ubuntu 16.04 (at which point I observed delivery problems). Next, I started with a stock Ubuntu 16.04 sendmail.mc file and slowly added things to it until I the problem reoccurred. I found that adding FEATURE(`ldap_routing', ...) to the stock sendmail.mc file is sufficient to reproduce this problem under Ubuntu 16.04.

Fuller problem report: The problem occurs when a (remote) SMTP host delivers e-mail over port 25 to the affected Ubuntu 16.04 system. Ubuntu's 16.04 sendmail process will report that it has accepted the e-mail message (over port 25), but the e-mail message is never delivered. Running 'ps auxwww | grep sendmail' on the Ubuntu 16.04 system after delivering an e-mail message to it, the sendmail child process reports that it's still accepting the message, like it hasn't finished processing it. This sendmail process hangs around indefinitely (I've waited days), and never finishes processing. If I kill the child sendmail process that was spawned to accept/process this message, at the next sendmail queue run interval the message is read from mqueue and properly delivered.

When I run strace -p <sendmail_accept_pid>, it shows the sendmail process is waiting for input from FD 3 (<unfinished> read(3, ...)).
When I start the sendmail daemon as "strace -f /usr/sbin/sendmail-mta -Am -L sm-mta -bd -q10m", I still get the same behavior where the child process accepting the e-mail message will get hung up waiting for input on FD3. Examining /proc/<PID>/fd/3 shows it to be a connection to a socket. When I backtrace through the strace output, it appears that FD3 is a socket to /dev/log, which strongly implies that sendmail isn't reading from the correct FD.

If I start sendmail as "/usr/sbin/sendmail-mta -Am -L sm-mta -bd -q10m -D /tmp/log", then sendmail seems to work fine (it accepts messages and promptly delivers them). This makes me think a file descriptor leak/mixup bug is triggered when the LDAP code is enabled.

The bug.apport output is included as a file attachment.