group.of.nepali.translators team mailing list archive

[Andreas Hasenack <andreas@xxxxxxxxxxxxx>]

The patch 0034 mentioned in comment #10 is applied in the xenial package
2.1.26.dfsg1-14build1, so what Roberto hit could be a different issue
requiring a different fix.

Might have been this:
cyrus-sasl2 (2.1.26.dfsg1-15) unstable; urgency=medium

  * Add fix for auth_rimap infinite loop (hang) when IMAP server closes
    connection (Closes: #815208)

Patch is https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=815208;filename=auth_rimap_socket_closed.patch;msg=5:
--- a/saslauthd/auth_rimap.c
+++ b/saslauthd/auth_rimap.c
@@ -494,7 +494,7 @@
         while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) {
            if ( FD_ISSET(s, &perm) ) {
               ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
-              if ( ret<0 ) {
+              if ( ret<=0 ) {
                  rc = ret;
                  break;
               } else {
@@ -607,7 +607,7 @@
         while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) {
            if ( FD_ISSET(s, &perm) ) {
               ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
-              if ( ret<0 ) {
+              if ( ret<=0 ) {
                  rc = ret;
                  break;
               } else {


** Also affects: cyrus-sasl2 (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Changed in: cyrus-sasl2 (Ubuntu Precise)
       Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/997217

Title:
  salsauthd maxes cpu

Status in cyrus-sasl2 package in Ubuntu:
  Fix Released
Status in cyrus-sasl2 source package in Precise:
  Won't Fix
Status in cyrus-sasl2 source package in Trusty:
  Triaged
Status in cyrus-sasl2 source package in Xenial:
  Triaged

Bug description:
  sasl2-bin version 2.1.24~rc1.dfsg1+cvs2011-05-23-4ubuntu contains a
  bug that causes heavy cpu utilization, impacting normal operation of
  one of our mail servers following an upgrade to Ubuntu 12.04.

  We are running the daemon with the following options:

  /usr/sbin/saslauthd -a rimap -O our.imap.server -r -m
  /var/spool/postfix/var/run/saslauthd -n 5

  
  We noticed that users were unable to send mail and that the saslauthd processes were using approximately 100% of each cpu core. An strace of one of the runaway process showed that it was stuck in the following behaviour:

  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  select(9, [8], NULL, NULL, {0, 0})      = 1 (in [8], left {0, 0})
  read(8, "", 940)                        = 0
  .....

  
  with further inspection showing that the file descriptor in question was a socket connected to our imap server in CLOSE_WAIT.

  Browsing saslauthd/auth_rimap.c in the source package for sasl2-bin,
  we came across the following code, repeated in two locations:

  while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) {
             if ( FD_ISSET(s, &perm) ) {
                ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
                if ( ret<0 ) {
                   rc = ret;
                   break;
                } else {
                   rc += ret;
                }
             }
          }

  
  It looks like this loop is expected to run until a read error is encountered or the timeout of 1 second is reached. There is no test to check that 0 bytes were read, indicating that the connection was closed by the remote peer. Since select() will immediately return the size of the set of the partially closed descriptor (1, which is >0), and calls to read() will always yield 0 bytes, there's the potential for execution to get stuck in this non blocking loop and I'm presuming that that's what's happening here.

  We've not performed any further analysis to prove that this is really
  what's happening but if my intuition is correct then our IMAP server
  (an nginx imap proxy) most liklely closes the connection at an
  unexpected time under as yet undetermined conditions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/997217/+subscriptions