From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
When ldap is enabled for automount in /etc/nsswitch.conf and you are
disconnected from the network, it takes several minutes for automount to start
up and display "OK" on the bootup screen.
Using "bash -x autofs start", I was able to track this down to a call from the
/etc/init.d/autofs startup script to a binary in /usr/lib/autofs called
autofs-ldap-auto-master. There is no man page and no help page for this binary
to indicate what it does. When run by hand and connected to the network, it
exits with a zero (0) status. When disconnected from the network, it exits with
a two (2) status and displays the the text that it could not bind to the ldap
server after about three minutes.
The autofs startup script seems to ignore the exit status of this binary and it
redirects the stderr output to /dev/null.
An strace on the autofs-ldap-auto-master binary shows it trying to do the
reverse address lookup in DNS for the ldap server (specified in IP format in
/etc/ldap.conf and /etc/openldap/ldap.conf). The binary tries numerous times,
which takes several minutes. After eventually failing to perform this lookup, it
tries anyway to access the ldap server, which fails quickly.
When the autofs-ldap-auto-master binary is run with an invalid argument, it
displays a usage message that documents the possible valid arguments. None of
them allow for a timeout so the binary is forced to wait for as long as it takes
to stop trying to do the reverse address resolution for the ldap server.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. enable ldap for automount in nsswitch.conf
2. set up an ldap map for automount in auto.master
3. disconnect system from network
4. /etc/init.d/autofs start
5. wait for several minutes ...
Actual Results: Several minute delay
Expected Results: Short delay
After researching other autofs bugs, I see now how the autofs-ldap-auto-master
output is used in a piped command. It is nested several layers into
getrawmounts. The output of all the getXXXmounts are used to construct
"automount" commands for starting up multiple instances of automount.
The long delay is still a pain though. It forces the user to wait for several
additional minutes when not connected to their home network.
We issue a synchronous ldap call. We can change this to be
asynchronous, and indeed, that is what I would prefer as well. I'm
changing the product and version to fedora.
I misread this before. The real complain is that the reverse lookup for the
server name is taking a long time. There's really nothing autofs can do about
that. I'm closing this as WONTFIX.
There may be enhancements to init scripts in the future that would preclude
services that require the network to be started if the network is unavailable.
This sounds like the right approach, moving forward.