Public bug reported: 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 processing/delivery until I took the .cf file from my Ubuntu 14.04 system and used it with the Ubuntu 16.04 sendmail package (at which point I observed delivery problems). For troubleshooting, I used a stock Ubuntu 16.04 sendmail.mc file and slowly added things to it until I the problem reoccurred. I have 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. ** Affects: sendmail (Ubuntu) Importance: Undecided Status: New ** Attachment added: "bug.apport" https://bugs.launchpad.net/bugs/1649700/+attachment/4791293/+files/bug.apport ** Description changed: 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 + 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. + 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. + until I took the .cf file from my Ubuntu 14.04 system and used it with + the Ubuntu 16.04 sendmail package (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. ** Description changed: 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 - until I took the .cf file from my Ubuntu 14.04 system and used it with - the Ubuntu 16.04 sendmail package (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. + Ubuntu 14.04 systems. I had no problems with sendmail + processing/delivery until I took the .cf file from my Ubuntu 14.04 + system and used it with the Ubuntu 16.04 sendmail package (at which + point I observed delivery problems). For troubleshooting, I used a + stock Ubuntu 16.04 sendmail.mc file and slowly added things to it until + I the problem reoccurred. I have 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1649700 Title: Sendmail 8.15.2 - hangs accepting e-mail with LDAP enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sendmail/+bug/1649700/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
