[Touch-packages] [Bug 997217] Re: salsauthd maxes cpu
I reply to myself: while the version in Xenial is *still* affected with
this bug, any of the later versions is fixed. The version
2.1.26.dfsg1-14 is bugged, but the next one, 2.1.26.dfsg1-15 is not. I
backported the one in Bionic easily and it's working now without
problems.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
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:
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, , NULL, NULL, ) >0 ) {
if ( FD_ISSET(s, ) ) {
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 997217] Re: salsauthd maxes cpu
I'm seeing this exact same problem with saslauthd in sasl2-bin
2.1.26.dfsg1-14, using Ubuntu 16.04.4. Is there any other possible
cause?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
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:
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, , NULL, NULL, ) >0 ) {
if ( FD_ISSET(s, ) ) {
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1321854] Re: useradd doesn't add the default shell to /etc/passwd entry
Could this be a sign of useradd ignoring everything in /etc/default/useradd? I've stumbled upon a problem when changing the default HOME base directory. Example: # useradd -D GROUP=100 HOME=/tmp INACTIVE=-1 EXPIRE= SHELL=/bin/sh SKEL=/etc/skel CREATE_MAIL_SPOOL=no # useradd -m testuser14 # grep testuser14 /etc/passwd testuser14:x:5012:5012::/home/testuser14: I think useradd is not only ignoring the SHELL variable (though I didn't change it in this example), but also the rest of variables that appear in /etc/default/useradd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1321854 Title: useradd doesn't add the default shell to /etc/passwd entry Status in shadow package in Ubuntu: Triaged Status in shadow source package in Trusty: Triaged Bug description: useradd is not honoring the default shell listed in /etc/defaults/useradd when creating new users. useradd -D showing the defaults. SHELL=/bin/bash # useradd -D GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel CREATE_MAIL_SPOOL=no Using useradd to create user test1. The /etc/passwd entry has a blank shell field: # useradd test1 # grep test1 /etc/passwd test1:x:2080:2080::/home/test1: Using useradd -s does populate the shell field: # useradd -s /bin/bash test2 #grep test2 /etc/passwd test2:x:2081:2081::/home/test2:/bin/bash Why useradd instead of adduser: puppet uses useradd to do user creation. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: passwd 1:4.1.5.1-1ubuntu9 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 Date: Wed May 21 17:51:57 2014 Ec2AMI: ami-42dc302a Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-1d Ec2InstanceType: m3.large Ec2Kernel: aki-919dcaf8 Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: shadow UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.useradd: 2014-05-21T17:36:05.208686 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1321854/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
