Bug 154943 - saslauthd doesn't start early enough
saslauthd doesn't start early enough
Status: CLOSED DUPLICATE of bug 246900
Product: Fedora
Classification: Fedora
Component: cyrus-sasl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
: 154947 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-04-14 18:14 EDT by Nathan G. Grennan
Modified: 2009-01-23 11:36 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-23 11:36:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nathan G. Grennan 2005-04-14 18:14:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322 Galeon/1.3.20

Description of problem:
saslauthd is used by postfix and other mail software like cyrus-imapd for authencation. By default saslauthd starts at 95, while postfix starts at 80, and cyrus-imapd starts at 65. This creates a time window where postfix and cyrus-imapd have started, but saslauthd hasn't. So a user tries to authenicate, but fails because saslauthd isn't avaliable. In my case I also use mysql to store mail user authencation information. mysql starts at 64, and needs be to be running before saslauthd. So I have changed /etc/rc.d/init.d/saslauthd so that it starts at 64 instead of 95. Ideally we would want enough time delay bewteen mysql and saslauthd so that mysql has time to initialize. The same is true for saslauthd and cyrus-imapd.

Ideally if mysqld, postgresql, openldap, and anything else that might use be used by saslauthd could be kept before saslauthd, along with moving saslauthd before anything that might use it like postfix and cyrus-imapd.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install saslauthd, mysqld, and postfix
2. chkconfig saslauthd on ; chkconfig mysqld on ; chkconfig postfix on
3. ls -al /etc/rc.d/rc3.d

Actual Results:  S64mysqld -> ../init.d/mysqld
S80postfix -> ../init.d/postfix
S95saslauthd -> ../init.d/saslauthd

Expected Results:  S64mysqld -> ../init.d/mysqld
S64saslauthd -> ../init.d/saslauthd
S80postfix -> ../init.d/postfix

Additional info:
Comment 1 Marius Andreiana 2005-05-13 05:05:02 EDT
*** Bug 154947 has been marked as a duplicate of this bug. ***
Comment 2 Marius Andreiana 2005-05-13 05:09:02 EDT
Yes, this would be useful and more setups will work out of the box.
Comment 3 Nalin Dahyabhai 2005-09-13 15:51:06 EDT
Er, that creates a circle: slapd can be configured to use saslauthd, and slapd
starts with priority of 27.  And saslauthd may be configured to consult slapd, ugh.
Comment 4 Bill Nottingham 2005-09-13 16:17:55 EDT
Yeah, not sure how you solve that loop.
Comment 5 Bill Nottingham 2005-09-13 16:18:36 EDT
Ideally, you'd move to a dynamic system, where dependencies on startup would be
automatically generated based on whether or not postfix was using saslauthd, etc.
Comment 6 Nalin Dahyabhai 2005-09-13 17:36:30 EDT
I know!  We can use tsort!

Seriously though, LSB defines Required-Start and Should-Start magic comments
which attempt to provide a way out of this mess, but without being able to pick
up cues from the current configuration, it doesn't indicate a solution, either.
Comment 9 Bug Zapper 2008-05-13 21:59:23 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 10 Bug Zapper 2008-11-25 20:47:45 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
Comment 11 Tomas Mraz 2009-01-23 11:36:04 EST
We now have LSB headers in the init script so the saslauthd will start probably earlier. As written in earlier comments the correct order depends on concrete configuration of the services so there will probably be necessary a manual administrator intervention anyway.

*** This bug has been marked as a duplicate of bug 246900 ***

Note You need to log in before you can comment on or make changes to this bug.