Package: autofs
Version: 4.1.3+4.1.4beta2-10
Severity: important
I have a sarge server which uses autofs. When I did a dist-upgrade on
it today, from autofs 4.1.3+4.1.4beta2-7 to 4.1.3+4.1.4beta2-10, my
normal user login hung for a very long time because autofs got hung up for
several minutes on each of several different paths that it was checking.
(Eventually I did get a login shell prompt, but it took roughly 20-30
minutes!) I even rebooted the server, thinking that stopping and
restarting the userspace automount daemons had caused it to get into a
broken state (which I have seen happen before on another Debian system).
The reboot made no difference.
I logged in as root (directly through ssh) while this was going on, and
strace'd my login shell:
wooledg 27089 0.0 0.1 2624 1108 pts/2 Ss+ 08:00 0:00 -ksh
# strace -p 27089
Process 27089 attached - interrupt to quit
open("/net/home/wooledg/bin/.paths", O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open("/usr/bin/.paths", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
open("/bin/.paths", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("/usr/bin/X11/.paths", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
stat64("/usr/contrib/bin/X11", 0xbfffde50) = -1 ENOENT (No such file or
directory)
open("/etc/.paths", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
stat64("/net/appl/netscape", 0xbfffde50) = -1 ENOENT (No such file or
directory)
stat64("/net/appl/tool/share/bin", 0xbfffde50) = -1 ENOENT (No such file
or directory)
stat64("/net/appl/clin/bin", 0xbfffde50) = -1 ENOENT (No such file or
directory)
umask(0) = 022
umask(022) = 0
stat64("/usr/local/bin/uname", 0xbfffeb80) = -1 ENOENT (No such file or
directory)
[...]
"/net/home/wooledg" is my home directory, which is mounted by autofs.
This one works fine. I was able to see it in "df", and I was able to
get a listing of the files therein, as root, while all this was
happening.
"/net/appl/netscape" and "/net/appl/tool/share/bin" and
"/net/appl/clin/bin", among others, are directories that are in my $PATH
and which are all mounted by autofs. None of these were working
properly. The stat64() calls took several minutes each to time out.
Downgrading to autofs 4.1.3+4.1.4beta2-7 fixes this problem for me. My
user login works as expected once again.
Here's my configuration files, since they don't appear to be attached at
the bottom of this bug report automatically. (Hopefully they won't be
attached later....)
arc1:/# grep -v '^#' /etc/auto.master
/nfs /etc/auto.net
+auto.master
arc1:/# ypcat -k auto.master
/net/vol auto.vol -rw,hard,intr
/net/appl auto.appl -rw,hard,intr
/net/hosts -hosts -rw,hard,intr
/net/home auto.home -rw,hard,intr
arc1:/# ypmatch wooledg auto.home
imadev:/home/wooledg
^^^ That's the one that works fine. imadev is an HP-UX 10.20 box.
arc1:/# ypmatch netscape auto.appl
svr2:/dsk/3/netscape:${PLATFORM}${ARCH}${OSNAME}${OSREL}
^^^ That's one of the ones that fail. svr2 is an i386 Red Hat Linux 6.2 box.
arc1:/# ypmatch tool auto.appl
svr2:/dsk/3/tool:${PLATFORM}${ARCH}${OSNAME}${OSREL}
^^^ Another example. They all pretty much follow this pattern.
Here's part of the /var/log/daemon.log file:
May 24 09:06:28 arc1 automount[1734]: >> mount: RPC: Remote system error -
Connection timed out
May 24 09:06:28 arc1 automount[1734]: mount(nfs): nfs: mount failure
svr2:/dsk/3/tool/i686Linux2.4.27-2-686 on /net/appl/tool
May 24 09:06:28 arc1 automount[1734]: failed to mount /net/appl/tool
May 24 09:13:47 arc1 automount[19818]: >> mount: RPC: Remote system error -
Connection timed out
May 24 09:13:47 arc1 automount[19818]: mount(nfs): nfs: mount failure
svr2:/dsk/3/tool/i686Linux2.4.27-2-686 on /net/appl/tool
May 24 09:13:47 arc1 automount[19818]: failed to mount /net/appl/tool
May 24 09:14:45 arc1 automount[29279]: failed to mount /net/appl/tool
May 24 09:14:47 arc1 automount[29280]: failed to mount /net/appl/netscape
May 24 09:14:47 arc1 automount[29281]: >> mount:
svr1:/dsk/2/clin/i686Linux2.4.27-2-686 failed, reason given by server:
Permission denied
May 24 09:14:47 arc1 automount[29281]: mount(nfs): nfs: mount failure
svr1:/dsk/2/clin/i686Linux2.4.27-2-686 on /net/appl/clin
May 24 09:14:47 arc1 automount[29281]: failed to mount /net/appl/clin
I can see two distinct problems in the log. The first is the long
"Connection timed out" problem which repeats a few times. The second is
the "Permission denied", because I have forgotten to make an
i686Linux2.4.27-2-686 symlink over on svr2. But reverting to autofs -7
makes the timeouts not happen:
May 24 09:35:50 arc1 automount[9730]: failed to mount /net/appl/tool
May 24 09:35:54 arc1 automount[9732]: >> mount:
svr1:/dsk/2/clin/i686Linux2.4.27-2-686 failed, reason given by server:
Permission denied
May 24 09:35:54 arc1 automount[9732]: mount(nfs): nfs: mount failure
svr1:/dsk/2/clin/i686Linux2.4.27-2-686 on /net/appl/clin
May 24 09:35:54 arc1 automount[9732]: failed to mount /net/appl/clin
May 24 09:35:55 arc1 automount[9734]: >> mount:
svr1:/dsk/2/clin/i686Linux2.4.27-2-686 failed, reason given by server:
Permission denied
May 24 09:35:55 arc1 automount[9734]: mount(nfs): nfs: mount failure
svr1:/dsk/2/clin/i686Linux2.4.27-2-686 on /net/appl/clin
In this case, the login happens within seconds, instead of taking half
an hour. I don't care about the failures, because those PATH elements
are only needed on the HP-UX and Red Hat boxes where I had to build
things by hand from source....
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages autofs depends on:
ii debconf 1.4.30.13 Debian configuration management sy
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
-- debconf information:
* autofs/upgrade-from-broken-version:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
