From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
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: ipc_loop : socket accept
Jun 2 12:43:01 maas saslauthd: ipc_loop : accept:
Interrupted system call
googleing for this error message geve me this link from the cyrus-sasl
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):
Steps to Reproduce:
1. service saslauthd restart
2. wait for some time, usually not to long before this happens and the
authentication becomes unavailable
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)
I am getting the same failure with RHEL AS 3.
Using MECH=kerberos5 and running testsaslauthd always produces
Jul 21 13:32:32 localhost saslauthd: ipc_loop : socket
Jul 21 13:32:32 localhost saslauthd: ipc_loop : accept:
Interrupted system call
Eventually producing a Segmentation Fault
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
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.
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:
Once I edited /etc/nsswitch.conf to read "group: files nis" then
all was well again.
Sorry for the misdiagnosis!
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.
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
Marking resolved:currentrelease. If this is a problem in RHEL, reopen or file a