The "setautomntent: No such file or directory" issue just happened
again. automount -m shows pretty much what I'd expect it to show; all
of the expected maps are there. And /net works (it's the only map on
this machine that's specified in auto.master).
Restarting autofs will of course fix things. I'm going to turn up
autofs and sssd debugging and then reboot in the hopes that this issue
will happen again.
[...]
And it did. How odd. In fact, it seems that once this happens at boot,
it will continue to happen through multiple reboots until I restart
autofs manually with the system booted.
I set debug_level = 9 in the autofs and domain/default sections of
sssd.conf. However, I've no idea what I'm looking for. If I look in
sssd_autofs.log for the time when the error did occur, I can see the
request and the following bits:
(Tue Mar 29 18:06:18 2016) [sssd[autofs]] [lookup_automntmap_step]
(0x2000): Looking up automount maps from the DP
(Tue Mar 29 18:06:18 2016) [sssd[autofs]] [setautomntent_send] (0x2000):
lookup_automntmap_step is refreshing the cache, re-entering the mainloop
(Tue Mar 29 18:06:18 2016) [sssd[autofs]] [sss_dp_get_reply] (0x1000):
Got reply from Data Provider - DP error code: 1 errno: 11 error message:
Fast reply - offline
(Tue Mar 29 18:06:18 2016) [sssd[autofs]]
[lookup_automntmap_cache_updated] (0x0020): Unable to get information
from Data Provider
Error: 1, 11, Fast reply - offline
Will try to return what we have in cache
As a note, this is current Fedora 23, sssd-1.13.3-5.fc23.x86_64.
I don't want to spam the list with the full logs but I can send them
personally if it would help. I do need to return the machine to
service, though, so I'm not going to be able to do any debugging until
this happens again.
- J<