Bugzilla Bug 77077

Passing the --timeout option to automount, either via the auto.master file or
directly on the commandline does nothing under AMD64.  It works fine on x86,
however.

The commandline looks like this:

/usr/sbin/automount --timeout 1 /misc file /etc/autofs/auto.misc

Mounting works perfectly, but unmounting does not happen automatically after
any amount of time.

Reproducible: Always
Steps to Reproduce:
1. Run /usr/sbin/automount --timeout 1 /misc/file /etc/autofs/auto.misc
2. Try to mount something in /misc by accessing it (just ls it from a different
directory, don't cd to it)
3. Type 'mount' after a few seconds

Actual Results:  
The mount point still shows up, no matter how long you wait.

Expected Results:  
Unmount automatically after 1 second (or near that amount of time).

Portage 2.0.51-r3 (default-linux/amd64/2004.3, gcc-3.3.4,
glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r12 x86_64)
=================================================================
System uname: 2.6.9-gentoo-r12 x86_64 AMD Opteron(tm) Processor 246
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.1.1-r3
Headers:  sys-kernel/linux26-headers-2.6.8.1-r2
Libtools: sys-devel/libtool-1.5.2-r7
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-pipe -O2"
CHOST="x86_64-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config
/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref
/usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-pipe -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
ftp://mirror.pudas.net/gentoo http://gentoo.ccccom.com ftp://gentoo.ccccom.com"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X acpi alsa arts berkdb bitmap-fonts cdr crypt cups esd f77 fam flac
foomaticdb fortran gdbm gif gnome gpm gstreamer gtk imagemagick imlib ipv6 java
jp2 jpeg kde ldap libwww lzw lzw-tiff mad mikmod motif mozilla multilib ncurses
nls oggvorbis opengl oss pam pdflib perl png ppds python qt readline sdl slang
ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts usb userlocales
xml xml2 xmms xpm xrandr xv zlib"

This is not an AMD64 specific bug.  The problem is in the autofs >4.1.3
ebuilds.  If you emerge (exactly) version 4.1.3 you'll find that unmounting
works, however starting from -r1 the unmounting doesn't work anymore.  Seems
the applied patches break something there.  The behaviour is exactly the same
on i386 for me.

I'd suggest to change the hardware to all.

I can't reproduce this on x86 at all.

For testing, I have just one line in auto.master:
/mnt    /etc/autofs/auto.misc --timeout 5
and one line in auto.misc:
tmpx            -fstype=tmpfs,size=2M   :none
And here is my test script:
http://tirpitz.iat.sfu.ca/~robbat2/autofs.testscript

The cases for me (on both x86_64 and i386) where it does not seem to unmount is
for progam maps, such as the newly added auto.net (a Sun-style hosts automount
in /net/[host]/[nfs/share].  I only use these program maps.

I use a set of ldap entries in auto.master in my production setup.

I tried auto.net, and it doesn't even work for me at all.
The script gives the correct output when give an IP/hostname, but autofs fails:
Jan 11 02:00:29 x29 automount[12156]: mount(bind): mkdir_path /net/127.0.0.1/space failed: Operation not permitted

I'll dig into it further later this week.

I did a small reconstruction on a nfs-less machine (with nfs support compiled
into the kernel)

emerge autofs nfs-utils

setup a small exports file:
# cat /etc/exports
# /etc/exports: NFS file systems being exported.  See exports(5).
/home   127.0.0.1(rw,sync)

start the nfs daemon and portmapper:
# /etc/init.d/nfs start
# /etc/init.d/portmap start

check that nfs exports actually works:
# showmount -e localhost
Export list for localhost:
/home localhost

configure auto.master to have /net enabled:
# cat /etc/autofs/auto.master
# $Id: auto.master,v 1.3 2004/12/09 08:25:48 robbat2 Exp $
# Sample auto.master file
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(8).
/net    /etc/autofs/auto.net
#/misc  /etc/autofs/auto.misc
#/home  /etc/autofs/auto.home

set the timeout value for automount to a ridiculous low value in
/etc/conf.d/autofs, like:
daemonoptions='--timeout 6'

start autofs:
# /etc/init.d/autofs start

check the current mounts with mount or df
navigate to the directory /net/localhost/home
make sure you get out of the dir, so no single process locks it
check again with mount or df to see that the mounts do not get unmounted, not
even after 6 minutes (instead of seconds).

I'm sorry if this sounds like a newbie autofs howto, but at least it should
give you a quickstart in getting the same problem.  Emerging version =4.1.3
shows that the for the same config the unmounting works.

By following your exact instructions on another box, I still get the same
result I had before.
Jan 11 02:38:46 b17 automount[13188]: mount(bind): mkdir_path
/net/localhost/home failed: Operation not permitted

I'm wondering if the kernel is at issue here, or some package in ~x86.
The kernel on both of my machines is 2.6.9-gentoo-r4, and they are both running
~x86. I'm on net-fs/nfs-utils-1.0.6-r6 and net-nds/portmap-5b-r9.

Hmmm, thanks for trying.

I experience the issue on a 2.4.26-r6 kernel, a 2.6.9-r13(?) kernel, I just tested on the latest stable (2.6.10 kernel) and a 2.6 kernel on amd64.  They all act the same for me, normal stable packages.  NFS client and server support in kernel... nothing weird I can think of.

Have exactly the same problem: autofs does mount the cdrom but never umoumts it
(at least for a reasonable time).

autofs-4.1.3-r2
Downgrading to the masked '=autofs-4.1.3' FIXED the problem.

(I use udev if that makes any difference.)

kernel 2.6.9-gentoo-r13,
x86, CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer -pipe"

Yassen: could you please provide me with your /etc/autofs/* lines that are
uncommented?

I reported this bug and have since tried emerging the unpatched 4.1.3 version. 
It works fine when downgraded this way, so +1 on the =4.1.3 workaround.

Robin: thanks for caring; sure, here they come:

-- auto.master --
/misc   /etc/autofs/auto.misc   --timeout=2

-- auto.misc --
cdrom      -fstype=iso9660,ro,nosuid,nodev   :/dev/cdroms/cdrom0

(If you need anything else just let me know.)

I use x86 (AMD AthlonXP) and my DVDRW drive would not unmount (timeout) with
4.1.3-r2. I tried 4.1.3 and this problem was solved, but another one took its
place, that after I had assigned three removable drives it would not take any
more! I am not sure whether the problem was the number, or the alternative
/dev/ path I assigned in udev. Another problem was that the directories under
/misc/ would appear randomly for no reason when nothing was plugged in, and
could be opened as an empty folder (though not "unmounted" again). I then tried
the most recent 3.1.5-r6 version and it worked perfectly. The only criticism
that if I tried to open the mount point before it had enough time it would give
an error. It would have been nicer if it waited for a few seconds or a preset
time limit before giving up. Apart from that, it worked perfectly.

RedHat bug 133365: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133365

It's a problem there.  I haven't been motivated enough to figure out which patch in the rpm fixes it (there are a ton of patches in their latest src rpm).

But apparently someone knew about it and fixed it :)

If there is somebody that is a Debian user, and can tell me if it's fixed in
their latest version, that would be better (as my current patches are based off
the Debian ones).

Re: additional comment #12. I submitted that from another computer
and made a mistake! The actual version of autofs that worked for me
was 3.1.7-r5

Robin: a friend of mine reports the Debain package 4.1.3-8 to work.

Same problem here with kernel 2.6.9 and 2.6.10 (development-sources).
Better mark 4.1.3-r2 unstable!

I'm not going to mark it back as unstable, as the problems in the rest of 4.1.3
that are fixed in -r2 are too important. Not unmounting after a timeout is a
small glitch by comparision.

I am looking at the Debian fixes, so expect a new release that should have the
timeouts solved sometime tommorow.

Well, then I'd prefer to mark the whole 4.1 unstable, since autoUNmounting is
one of the most important things of automount, imho.  If it doesn't automount,
it is as good as assigning static entries in /etc/fstab.  Besides that, hanging
NFS mounts because the target hosts are not up any more are really annoying.

I use it for accessing a (usb mass storage) camera and cd/dvd and this way I
end up with stale mounts, so with 4.1.3-r2, the whole functionality is gone!
Going back to 3.1.7-r5 would definitely be a better choice!

automount does not time out for me, either, when using autofs-4.1.3-r2, kernel
gentoo-dev-sources-2.6.10-r4, and kernel module _autofs4_.  However, everything
works fine if I modprobe the _autofs_ module instead.

Nice workaround, works here too with development-sources-2.6.10.
However, modprobe autofs wants to load autofs4 anyway so the alias in /etc/modules.d/automount should be commented out and a modules-update has to be executed after that.

Removing autofs-4.1.3-signal-race-fix.patch from PATCH_LIST solves the problem
for autofs-4.1.3-r2. Timeout option works for me now.

Ok, I still can't reproduce this myself, but as some folk have noted specific
conditions that cause it and fix it, i've put into ~arch 4.1.3-r3, that takes
out the signal race fix.

Could everybody please try it and report back on it? (for working and not
working).

I've taken a look at the patch. It changes two things.

1) In st_prepare_shutdown ap.state used to be changed to ST_SHUTDOWN_PENDING 
before locking signals. With some assumptions, I can see why this would be a 
race condition. The patch switches the order of these two statements.

2) In st_expire ap.state was changed before unlocking signals. With the same 
assumptions as above, this would not be a race condition. The patch did switch
these two statements as well however.

The source of autofs-4.1.4_beta1 shows that upstream did include 1), but not 2).

Conclusion: 2) is incorrect.

Robin: if you want me to do the changes, gimme a holler

griffon26: if you'd like to, please go ahead (I'm just heading off to bed).

r3 Works! Now I can use the autofs4 kernel-module again :)

I added a modified version of the upstream race patch to portage. With this
patch, the timeout should still work while also fixing the race condition.

Please wait a little while (at least 30 mins iirc), emerge sync, and try -r3 
again. 

To verify you have the latest, check for this line in the ebuild:
    # Upstream version of this patch is incorrect

r3 still works here after this change...

did a sync but didn't get the updated version.  will try again tomorrow.

-r3 seems to work for me.

I'm sorry for the delay...

-r3 works good for me too!

Ok, closing then. Thanks for all your input, people!

I'm sorry if this is already done or against policies, but shouldn't 4.1.3-r3
been made stable now?  My machines still don't want to upgrade to -r3 while it
is certainly better than -r2, which it does want to upgrade to.  (I kept my
machines having 4.1.3, because that one still auto-unmounted.)

Again, my apologies in advance, because I'm a bit ignorant and haven't looked
for some policies on this.

I think gentoo forgot..., so now u have two options:

- 1. wait till gentoo finally markes r3 stable in favor of r2
- 2. echo "=net-fs/autofs-4.1.3-r3 ~x86" >>/etc/portage/package.keywords

I choose option 2 one week ago already when I found r3 to be stable :D

thanks... I more or less wanted to save me the hassle of going through all
machines and removing 4.1.3-r2 from package.mask and adding r3 to the
keywords... lol

I did not forget. Policy is to not mark a package stable until there is
reasonable
confidence that it is indeed stable. 

After fixing a bug, the new version will be ~x86 (or maybe even package
masked).
The only exceptions to this are security bugs and very serious bugs (think data
corruption).

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4

As maintainer, Robin Johnson will decide when it is time to mark the new
version stable. You can help him by reporting your experience after the package
has been
in ~x86 for a while.

Please read Robin's own comments on this thread:
http://thread.gmane.org/gmane.linux.gentoo.devel/25254

Thanks for your reply.  I fully understand the matter of stability, and sort of
`political' issues related with it.

I'm currently successfully running it on a few desktop machines, will try it
out on some heavily used servers where automounting (and unmounting) is fairly
important and exhaustingly used.

Sorry if this sounds pigheaded, but maybe you could make an exception in this
case because the auto-unmount feature, which is IMHO essential for autofs,
- does not work at all in the stable marked r2
- is fixed in r3
- is confirmed to be functioning in r3 a couple of times
- still works without any problems for over a week

It looks quite strange to me seeing a non functioning r2 marked as stable vs.
an excellent functioning r3 marked as unstable...
In this situation, the chance is big that people, emerging autofs for the first
time, will unnecessary bump upon this bug, giving people a reason to be
negative  about gentoo and we don't want that, do we?
My final comment to this bug ;-)

Hey.  I just want to say that r3 works perfectly on my system as well.

I've got one pending bug for autofs still (#81504), and a few other small fixes
that have been reported to me outside of bugzilla.
Those, plus a week of user testing, and I'd expect to have 4.1.3-r4 in stable.
(Yes, that isn't a typo, there will be an r4 with the fixes).

Works great for me under AMD64.

just a small update:

I haven't experienced any abnormalities with -r3 on my server.  It correctly unmounts and works like expected.

Just a small update:
I emerged -r4 since it became available, and it works fine for me (it unmounts and hasn't given any trouble yet).

r4 runs here already since march 21 without problems