Bug 90119 - autofs startup delayed when ldap enabled and not connected to network
autofs startup delayed when ldap enabled and not connected to network
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-05-02 15:54 EDT by Walter Rowe
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-08 18:49:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Walter Rowe 2003-05-02 15:54:53 EDT
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):

How reproducible:

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

Additional info:
Comment 1 Walter Rowe 2003-05-02 16:06:59 EDT
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.
Comment 2 Jeffrey Moyer 2004-09-20 17:10:07 EDT
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.

Comment 4 Jeffrey Moyer 2006-05-08 18:49:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.