>>>>> "JH" == Jakub Hrozek
<jhrozek(a)redhat.com> writes:
JH> Yes, that's what I would expect, too. It would be nice to see the
JH> autofs responder logs.
I can crank up the debugging. At least this one is trivial to reproduce
(just boot with the network unplugged).
JH> Do you know if SSSD is running at that point? Isn't it 'just' a race
JH> between sssd and autofs services?
It's not really easy to tell, but here's a snippet from a log (just the
first entry I found on a machine where I know this has happened):
Mar 28 11:45:24
ld65.e.math.uh.edu sssd[745]: Starting up
Mar 28 11:45:24
ld65.e.math.uh.edu sssd[be[default]][750]: Starting up
Mar 28 11:45:24
ld65.e.math.uh.edu sssd[nss][765]: Starting up
Mar 28 11:45:24
ld65.e.math.uh.edu sssd[pam][766]: Starting up
Mar 28 11:45:24
ld65.e.math.uh.edu sssd[autofs][764]: Starting up
Mar 28 11:45:24
ld65.e.math.uh.edu audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=sssd comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=?
addr=? terminal=? res=success'
The network came up here:
Mar 28 11:45:26
ld65.e.math.uh.edu NetworkManager[722]: <info>
(enp3s0): Activation: successful, device activated.
And then autofs startup completed:
Mar 28 11:45:31
ld65.e.math.uh.edu audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=autofs
And the error:
Mar 28 11:45:31
ld65.e.math.uh.edu automount[900]: setautomntent:
lookup(sss): setautomntent: No such file or directory
So it looks like sssd was at least started earlier, and the network was
up by the time the error was emitted.
JH> By the way, this reminds me of
JH>
https://bugzilla.redhat.com/show_bug.cgi?id=1113639 but that issue
JH> only happens with an empty cache, it looks like sssd doesn't even
JH> revert to cache in your case.
It did just occur to me that maybe I've configured the cache time way
down:
autofs_provider = ldap
ldap_autofs_entry_value = nisMapEntry
ldap_autofs_entry_object_class = nisObject
ldap_autofs_map_object_class = nisMap
ldap_autofs_map_name = nisMapName
ldap_autofs_entry_key = cn
entry_cache_autofs_timeout = 60
I did this way back when because machines were hanging onto old maps for
a really long time after I changed them (usually when moving home
directories around). Might this have something to do with the issue?
I don't think so, even if the cache was expired, then we should try to
fetch the maps, but on failure to do so, we should fall back to the
cache.