Package: sssd Version: 1.14.2 Problem description:
When autofs uses direct mappings and has SSSD as a provider, there is a race condition on upstart and systemd where autofs starts before SSSD's responders are active even though autofs is set to start after SSSD. This happens because SSSD is marked as started right after the monitor forks, instead of waiting until the responders are up. When this happens, autofs needs to be restarted manually (HUP) to start offering those mappings. Test case: - Configure an LDAP server containing the direct mappings for autofs (/direct) - 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, there won’t be errors: $ ls /direct ok - If autofs started before sssd finished starting an error will happen: $ ls /direct ls: cannot access '/direct': No such file or directory --- Might be related to bug #836576. This bug has been fixed upstream (milestone is 1.14.3) with this commit: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=d4063e9a21a4e203bee7e0a0144fa8cabb14cc46 Kind regards, Victor
