Bug 984089 - Consider adding After=sssd.service to autofs.service
Consider adding After=sssd.service to autofs.service
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-12 14:15 EDT by Jason Tibbitts
Modified: 2013-07-22 21:15 EDT (History)
3 users (show)

See Also:
Fixed In Version: autofs-5.0.7-28.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-22 21:15:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Tibbitts 2013-07-12 14:15:55 EDT
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 15:03:31 EDT
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 02:10:43 EDT
Sure, I'll add the "After=" to the unit file.
Comment 3 Fedora Update System 2013-07-13 02:45:15 EDT
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-13 23:27:07 EDT
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-22 21:15:02 EDT
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.

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