autofs does not recover from failure to read maps on startup

[Maciej Puzio]

This problem is occurring on Ubuntu 16.04 system where autofs and sssd are both installed, sssd is configured to provide automount maps, and nsswitch.conf directs autofs to use sssd. In a situation when both sssd and autofs start before network is up (which happens out-of-the-box because of bug 1588915), sssd is unable to obtain automount maps from the LDAP server, nor any other data, and serves information from its cache. Autofs does not appear to retrieve cached automount maps from sssd, which can be verified with automount -m not showing any maps. This is accompanied by an error in syslog: "setautomntent: lookup(sss): setautomntent: No such file or directory". It goes without saying that shares are not mounted either.

When network is finally up, sssd is able to connect to the LDAP server, and autofs retrieves automount maps (automount -m now displays maps as expected). However autofs does not attempt to mount shares specified by these maps. Attempting to access these shares does not help; it is necessary to manually restart autofs service.

Steps to reproduce:
1. Start the machine with network interfaces not configured (e.g. cables unplugged).
2. Verify that sssd works and serves data (e.g. getent passwd, etc).
3. Check that autofs does not see maps and has not mounted shares: automount -m, ls /shares/...
   (Possibly) expected result: autofs obtains cached maps and mounts shares as specified.
4. Plug network cable and configure the interface: ifup eth0
5. Verify that autofs now sees maps: automount -m
6. Check that shares specified in maps are still unmounted: ls /shares/...
   Expected result: shares will now be mounted.
7. Restart autofs: systemctl restart autofs
8. Verify that shares are now mounted.
   This is as expected, but step #7 shouldn't be necessary.

$ lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

$ apt-cache policy autofs sssd-ldap libpam-sss libnss-sss sssd-tools
autofs:
  Installed: 5.1.1-1ubuntu3
sssd-ldap:
  Installed: 1.13.4-1ubuntu1
libpam-sss:
  Installed: 1.13.4-1ubuntu1
libnss-sss:
  Installed: 1.13.4-1ubuntu1
sssd-tools:
  Installed: 1.13.4-1ubuntu1
[Note: Package sssd is not installed, because it is a virtually empty package that pulls a numbed of unneeded dependencies.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I uploaded a newer autofs to Zesty yesterday. This restores the systemd service, which was previously being replaced by an upstart job. On 16.04, I suspect (but haven't checked) that this caused a fallback to the init.d script. So on Zesty, behaviour may have changed in relation to this bug.

I'm not really sure how to address the issue you're facing, but we appreciate the report. Suggestions on how to do this properly welcome (I see some in bug 1588915?)

[Maciej Puzio (maciej-puzio)]

Robie, thank you for your comment.
There is a number of bugs related to autofs and sssd present in Xenial. A partial attempt to sort out this situation can be found in bug 1566508, comment #20 (https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1566508/comments/20 ). However, this is compounded by problems with network interface initialization on startup: bug 1588915, comment #12 (https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1588915/comments/12 ). Both of these bug reports deal with several issues that are difficult to untangle.
Regarding the issue of missing autofs.service file, it a subject of bug 1614248.

[Bryce Harrington (bryce)]

LP: #1566508 looks like it's been resolved, and LP: #1614248 appears still an issue in xenial but fixed in zesty and newer. LP: #1588915 is still open but seems to be an ifupdown bug rather than autofs itself, and has not been updated since 2017 and I'm not sure if it is still an issue on newer releases.

From what I understand, this bug report was filed due to the amalgamation of issues that made this use case malfunction. Given that it appears a number of improvements have been introduced since 16.04, and given that standard support for 16.04 has ended, I think we should consider this bug report resolved, and if there are remaining issues reproducible on newer Ubuntu releases, to have fresh new bug(s) filed for them. Meanwhile, thanks again for raising this issue with us.