Bug 984089

Summary:	Consider adding After=sssd.service to autofs.service
Product:	[Fedora] Fedora	Reporter:	Jason Tibbitts <j>
Component:	autofs	Assignee:	Ian Kent <ikent>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	ikent, jdorff, jhrozek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	autofs-5.0.7-28.fc19	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-23 01:15:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jason Tibbitts 2013-07-12 18:15:55 UTC

autofs can start before sssd, leading to this:

Jul 12 11:11:33 ld81.e.math.uh.edu automount[942]: setautomntent: lookup(sss): setautomntent: Connection refused

and autofs not being able to fetch auto.master.  Of course, you need "automount: files sss" in /etc/nsswitch.conf for this to matter.

For whatever reason, I didn't see this startup race in either F17 or F18, or if I did it happened extraordinarily rarely.  But I can repeat it at will on a F19 machine I just brought up (though that machine has twelve cores, which could simply mean that the issue only shows up when you have an large amount of parallelism).

Running a fresh F19 install, with autofs-5.0.7-23.fc19.x86_64

Creating /etc/systemd/system/autofs.service.d/after-sssd.conf containing:

[Unit]
After=network.target ypbind.service sssd.service

appears to fix the problem for me.  Just using that in the main unit file would do it as well.  This doesn't add any dependency on sssd, just makes sure that if sssd is going to start on the system, autofs starts after it.  I'm trying to imagine a situation where this ordering would cause problems but I can't come up with one.

Comment 1 Jason Tibbitts 2013-07-12 19:03:31 UTC

As an aside, for whatever reason I can reproduce this every time on a machine with 12 cores, 32GB of RAM and plain old rotating disk while I can't reproduce it at all on a machine with 4 cores, 16GB of RAM and a SSD.  The speed of the cores and RAM are pretty close to the same (same CPU generation, Sandy Bridge) and the machines were identically kickstarted so maybe the increased parallelism and slower IO is enough to trigger the race.

Comment 2 Ian Kent 2013-07-13 06:10:43 UTC

Sure, I'll add the "After=" to the unit file.

Comment 3 Fedora Update System 2013-07-13 06:45:15 UTC

autofs-5.0.7-28.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/autofs-5.0.7-28.fc19

Comment 4 Fedora Update System 2013-07-14 03:27:07 UTC

Package autofs-5.0.7-28.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing autofs-5.0.7-28.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-12952/autofs-5.0.7-28.fc19
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2013-07-23 01:15:02 UTC

autofs-5.0.7-28.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.