Bug 154943

Summary:	saslauthd doesn't start early enough
Product:	[Fedora] Fedora	Reporter:	Nathan G. Grennan <redhat-bugzilla>
Component:	cyrus-sasl	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED DUPLICATE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	10	CC:	k.georgiou, marius.andreiana, notting
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-01-23 16:36:04 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 Nathan G. Grennan 2005-04-14 22:14:03 UTC

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):
cyrus-sasl-2.1.20-4

How reproducible:
Always

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 09:05:02 UTC

*** Bug 154947 has been marked as a duplicate of this bug. ***

Comment 2 Marius Andreiana 2005-05-13 09:09:02 UTC

Yes, this would be useful and more setups will work out of the box.

Comment 3 Nalin Dahyabhai 2005-09-13 19:51:06 UTC

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 20:17:55 UTC

Yeah, not sure how you solve that loop.

Comment 5 Bill Nottingham 2005-09-13 20:18:36 UTC

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 21:36:30 UTC

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-14 01:59:23 UTC

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bug Zapper 2008-11-26 01:47:45 UTC

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Tomas Mraz 2009-01-23 16:36:04 UTC

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 ***