Bug 125166

Summary: saslauthd crashes with "Interrupted system call"
Product: [Fedora] Fedora Reporter: David Jansen <jansen>
Component: cyrus-saslAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 2CC: mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-04 12:37:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Jansen 2004-06-03 11:45:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
I use saslauthd for SMTP authentication on a mail server. On a regular
basis, saslauthd dies and leaves a message in /var/log/messages:

Jun  2 11:43:37 maas saslauthd: saslauthd startup succeeded
Jun  2 12:42:58 maas saslauthd[19605]: ipc_loop        : socket accept
failure
Jun  2 12:43:01 maas saslauthd[19605]: ipc_loop        : accept:
Interrupted system call

googleing for this error message geve me this link from the cyrus-sasl
mailing list: 
http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=5310

one of the replies states that it is a bug, fixes in version 2.1.17,
but fedora core 1 comes with 2.1.15, and the changelog of the rpm has
nothing about a backported patch

Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.15-6

How reproducible:
Sometimes

Steps to Reproduce:
1. service saslauthd restart
2. wait for some time, usually not to long before this happens and the
authentication becomes unavailable
3.
    

Actual Results:  smtp authentication no longer possible so users can
not send e-mail unless authenticated in another way (or host listed in
allowed list for relaying)

Additional info:

Comment 1 Jarod Beekman 2004-07-21 20:44:00 UTC
I am getting the same failure with RHEL AS 3.
cyrus-sasl-2.1.15-8.

Using MECH=kerberos5 and running testsaslauthd always produces 

Jul 21 13:32:32 localhost saslauthd[11537]: ipc_loop        : socket 
accept failure
Jul 21 13:32:32 localhost saslauthd[11537]: ipc_loop        : accept: 
Interrupted system call

Eventually producing a Segmentation Fault


Comment 2 Paul Heinlein 2004-08-11 22:23:35 UTC
Similar symptoms on FC 2 (cyrus-sasl-2.1.18-2), except there
are no ipc_loop log entries, which were eradicated I believe
in the upstream 2.1.17 source.

I can always reproduce the problem by using the Mail.app that
ships with 10.3.5 (earlier versions, afaict, don't have the
problem). In any case, it's a client-initiated problem and
therefore a potential denial-of-service scenario.

I'm using MECH=pam and we're using NIS for most of the password
map.

It looks like the problem client will take out one (and only
one) saslauthd thread/process each time it tries to
authenticate. If it takes out a child thread (parent pid > 1),
then other users can still authenticate. If it takes out the
master thread (parent pid == 1), then no one can authenticate.

Comment 3 Paul Heinlein 2004-08-13 17:22:41 UTC
You can disregard my comment dated 2004-08-11 18:23; the
problems were due to the "more than 8 groups" bug outlined
in ticket #125653:

   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125653

Once I edited /etc/nsswitch.conf to read "group: files nis" then
all was well again.

Sorry for the misdiagnosis!

Comment 4 Matthew Miller 2005-04-26 15:22:17 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 5 David Jansen 2005-05-04 11:47:08 UTC
Since switching to FC3 I haven't seen this problem again, I guess the bug is
closed then (unless of course it is still present in RHEL as reported in comment #1

Comment 6 Matthew Miller 2005-05-04 12:37:34 UTC
Marking resolved:currentrelease. If this is a problem in RHEL, reopen or file a
new bug.