autofs races with sssd on startup
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sssd (Ubuntu) |
Fix Released
|
Medium
|
Victor Tapia | ||
Trusty |
Fix Released
|
Medium
|
Victor Tapia | ||
Xenial |
Fix Released
|
Medium
|
Victor Tapia | ||
Yakkety |
Fix Released
|
Medium
|
Victor Tapia |
Bug Description
[Impact]
* SSSD is set as started before its responders are active.
* Depending services (e.g. autofs) start before those responders are working, and a manual restart is required to make them work after boot
* This happens with upstart and, with less frequence, systemd
[Test Case]
* Configure an LDAP server containing the direct mappings for autofs
* Configure SSSD to read from that LDAP server
* Add ‘automount: sss’ to /etc/nsswitch.conf
* Reboot the machine, login, and try reading the contents of a direct mapping.
* If the environment has booted correctly the mapping will be available. Otherwise, it will not.
[Regression Potential]
* This is a cherry-pick from an upstream fix
* sssd could not start automatically
[Other Info]
* Upstream commit: https:/
[Original Description]
This report concerns a configuration where autofs and sssd are both installed, sssd is configured to provide automount maps, and nsswitch.conf directs autofs to use sssd. In such a configuration autofs often fails on boot complaining "no mounts in table". This is because autofs may be started before sssd, or after sssd is started but before its autofs support is ready. If this happens, one can restart autofs and it will work fine.
This bug affects other users:
* Bug 40189 "autofs needs to be restarted to pick up some shares" - a very old bug with invalid status, but see last comment #46, complaining about Ubuntu trusty: https:/
* Link to SSSD-users mailing list, also complaining about Ubuntu trusty: https:/
$ lsb_release -rd
Description: Ubuntu 14.04.4 LTS
Release: 14.04
$ apt-cache policy autofs sssd
autofs:
Installed: 5.0.7-3ubuntu3.2
sssd:
Installed: 1.11.5-1ubuntu3
$ uname -a
Linux **** 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Workaround:
Edit /etc/init/autofs as shown in attached files (both full file and diff provided). Unfortunately, this modification will work only in this particular configuration, thus it is not a good candidate for a patch.
Explanation:
We have to deal with two problems here:
1. Autofs starts on runlevel [2345], and in effect its startup order in relation to sssd is random. We fix this by changing start stanza to "start on started sssd".
2. Unfortunately this is not enough, because sssd emits started event too early, before its autofs support is ready. To work around this, we add a loop to pre-start script that waits for sssd to start listening on /var/lib/
tags: | added: sts |
Changed in autofs (Ubuntu): | |
status: | Confirmed → Invalid |
Changed in sssd (Ubuntu): | |
status: | Confirmed → In Progress |
assignee: | nobody → Victor Tapia (vtapia) |
description: | updated |
no longer affects: | autofs (Ubuntu) |
Changed in sssd (Ubuntu): | |
importance: | Undecided → Critical |
importance: | Critical → Medium |
tags: | added: sts-sponsor sts-sru |
Changed in sssd (Ubuntu Trusty): | |
assignee: | nobody → Victor Tapia (vtapia) |
Changed in sssd (Ubuntu Xenial): | |
assignee: | nobody → Victor Tapia (vtapia) |
Changed in sssd (Ubuntu Yakkety): | |
assignee: | nobody → Victor Tapia (vtapia) |
importance: | Undecided → Medium |
Changed in sssd (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in sssd (Ubuntu Trusty): | |
importance: | Undecided → Medium |
Changed in sssd (Ubuntu Trusty): | |
status: | New → In Progress |
tags: | removed: sts-sponsor |
tags: |
added: sts-sru-needed removed: sts-sru |
tags: |
added: verification-failed removed: verification-done-xenial verification-done-yakkety verification-needed |
tags: |
added: verification-failed-xenial verification-failed-yakkety removed: verification-failed |
tags: |
added: verification-done removed: verification-needed |
tags: |
added: verification-done-trusty removed: verification-done |
tags: | added: verification-done-xenial |
As mentioned in the description, Autofs starts before SSSD's responders are running, even though SSSD is set to start before Autofs, both in upstart and systemd. The problem is related to the boot process of SSSD because upstart/systemd determine the job as started right after sssd forks, when in reality it's still starting the providers and responders that other services (e.g. autofs) might require.
Regarding AutoFS's required start: if AutoFS starts before SSSD, it'll have an empty mapping table. Once SSSD is running AutoFS will populate it, but only the indirect maps would be applied. According to its man page: Direct maps require a HUP signal be sent to the daemon to refresh their contents as does the master map.
In previous releases, SSSD delayed the creation of its pidfile to address this issue (https:/ /git.fedorahost ed.org/ cgit/sssd. git/commit/ ?id=d19c4785215 305e6eb5f2fa2fc 503a2ba50d3f10). I'll try to bring this back and experiment with the results.
I'm going to provide a different workaround based on sssd.