Comment 20 for bug 1566508

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]