[Bug 1566508] Re: autofs races with sssd on startup

[Maciej Puzio]

Here is my attempt to sort out how many bugs are related to autofs
failing on boot.

This bug (1566508) 
As noted earlier, these are actually two issues:
1. autofs starts before sssd.
2. autofs starts after sssd, but before sssd responders are up.
On Trusty, I observed #1 and #2, and on Xenial I observed neither, while Victor Tapia reported only observing #2 on Xenial (comment #13).
Regarding the apparent fix for #1 in Xenial, I believe that it is accidental, and the proper fix is subject of bug 1614248. Regarding #2 in Xenial, I can only say that I tried very hard to reproduce it, and I could not.

In this bug we also discuss another issue that was not subject of the original bug report:
3. sssd trying to connect to its providers (e.g. LDAP) before network is ready.
On Trusty, I observed it only very rarely, but in Xenial this issue occurred on every boot. Victor Tapia reports observing this problem on both Trusty and Xenial.

I do not think that creating a new autofs or sssd bug for this issue
would be a good idea, because this problem is not caused directly by
autofs or sssd, but rather is a result of ifupdown bug 1588915 (at least
this is so on Xenial).

However this bug would be no reason of concern if autofs were able to recover from an initial map read failure. There are two issues here, both covered by bug 1614282:
4. autofs does not appear to read cached automount maps from sssd.
5. autofs does not mount shares even when it is finally able to read maps from sssd, after network is up and sssd has been able to receive maps from its provider (e.g. LDAP).

Regarding #4, the problem may lie with sssd rather than autofs. I am not sure if this issue is related to problem mentioned by Jakub Hrozek in comment #9. However, Jakub's patch will fix #4 (possibly), but not #5; we also want autofs to mount shares, when possible, even when there were no maps in cache on startup.
As to Victor's comment #3, I observed the problem with indirect maps. All maps, including the master map, come from the LDAP server, so perhaps it's the master map that is not updated automatically, rendering everything unusable. Unfortunately, my tests with sending HUP to automount daemon did not produce results as described in the manpage (yet another bug?). In any case, the logic that manpage describes as "change on the fly" should not apply to the situation when there is no master map whatsoever due to an earlier error (as is our case).

Links to related bugs:
Bug 1588915 ifup does not block for interface to be up with static addresses 
Bug 1614248 Package autofs does not include autofs.service file
Bug 1614282 autofs does not recover from failure to read maps on startup
Bug 1584818 autofs fails to read sss [duplicate, but difficult to say what of; most likely referring to issue #3]

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to autofs in Ubuntu.
https://bugs.launchpad.net/bugs/1566508

Title:
  autofs races with sssd on startup

Status in autofs package in Ubuntu:
  Confirmed
Status in sssd package in Ubuntu:
  Confirmed

Bug 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://bugs.launchpad.net/ubuntu/+source/autofs/+bug/40189/comments/46
  * Link to SSSD-users mailing list, also complaining about Ubuntu trusty: https://lists.fedorahosted.org/pipermail/sssd-users/2015-July/003166.html

  $ 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/sss/pipes/autofs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1566508/+subscriptions