Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 77077 - net-fs/autofs: Automount does not timeout.
Summary: net-fs/autofs: Automount does not timeout.
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Robin Johnson
Depends on:
Reported: 2005-01-07 14:59 UTC by Chris Monson
Modified: 2011-05-21 12:23 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Chris Monson 2005-01-07 14:59:03 UTC
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.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-
Headers:  sys-kernel/linux26-headers-
Libtools: sys-devel/libtool-1.5.2-r7
CFLAGS="-pipe -O2"
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"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
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"
Comment 1 Fabian Groffen gentoo-dev 2005-01-10 10:15:06 UTC
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.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-01-10 21:01:06 UTC
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:

Comment 3 Fabian Groffen gentoo-dev 2005-01-10 22:52:07 UTC
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 (a Sun-style hosts automount in /net/[host]/[nfs/share].  I only use these program maps.
Comment 4 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-01-11 02:07:39 UTC
I use a set of ldap entries in auto.master in my production setup.

I tried, 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/ failed: Operation not permitted

I'll dig into it further later this week.
Comment 5 Fabian Groffen gentoo-dev 2005-01-11 02:30:57 UTC
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).

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/
#/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.
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-01-11 02:44:35 UTC
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.
Comment 7 Fabian Groffen gentoo-dev 2005-01-11 02:50:17 UTC
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.
Comment 8 Yassen Damyanov 2005-01-14 13:02:35 UTC
Have exactly the same problem: autofs does mount the cdrom but never umoumts it (at least for a reasonable time).

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"
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-01-14 13:36:41 UTC
Yassen: could you please provide me with your /etc/autofs/* lines that are uncommented?
Comment 10 Chris Monson 2005-01-15 11:39:08 UTC
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.
Comment 11 Yassen Damyanov 2005-01-17 00:39:04 UTC
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.)
Comment 12 Dave Spagnol 2005-01-20 09:29:40 UTC
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.
Comment 13 Andy Wang 2005-01-20 13:54:35 UTC
RedHat bug 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 :)
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-01-20 14:49:20 UTC
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).
Comment 15 Dave Spagnol 2005-01-20 15:35:24 UTC
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
Comment 16 Yassen Damyanov 2005-01-21 02:16:29 UTC
Robin: a friend of mine reports the Debain package 4.1.3-8 to work.
Comment 17 Evert 2005-01-23 12:20:52 UTC
Same problem here with kernel 2.6.9 and 2.6.10 (development-sources).
Better mark 4.1.3-r2 unstable!
Comment 18 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-01-23 15:33:01 UTC
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.
Comment 19 Fabian Groffen gentoo-dev 2005-01-24 00:02:13 UTC
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.
Comment 20 Evert 2005-01-25 11:20:20 UTC
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!
Comment 21 Jonathan Stickel 2005-01-27 09:31:53 UTC
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.
Comment 22 Evert 2005-01-27 10:43:32 UTC
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.
Comment 23 Ojec Borec 2005-02-05 00:50:16 UTC
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.
Comment 24 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-02-05 02:40:32 UTC
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).
Comment 25 Maurice van der Pot (RETIRED) gentoo-dev 2005-02-05 03:24:55 UTC
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
Comment 26 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-02-05 03:58:57 UTC
griffon26: if you'd like to, please go ahead (I'm just heading off to bed).
Comment 27 Evert 2005-02-05 04:28:08 UTC
r3 Works! Now I can use the autofs4 kernel-module again :)
Comment 28 Maurice van der Pot (RETIRED) gentoo-dev 2005-02-05 04:51:38 UTC
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 

To verify you have the latest, check for this line in the ebuild:
    # Upstream version of this patch is incorrect
Comment 29 Evert 2005-02-05 05:50:09 UTC
r3 still works here after this change...
Comment 30 Fabian Groffen gentoo-dev 2005-02-05 06:23:55 UTC
did a sync but didn't get the updated version.  will try again tomorrow.
Comment 31 Abraham Smith 2005-02-05 06:32:33 UTC
-r3 seems to work for me.
Comment 32 Fabian Groffen gentoo-dev 2005-02-10 09:06:46 UTC
I'm sorry for the delay...

-r3 works good for me too!
Comment 33 Maurice van der Pot (RETIRED) gentoo-dev 2005-02-10 09:16:36 UTC
Ok, closing then. Thanks for all your input, people!
Comment 34 Fabian Groffen gentoo-dev 2005-02-13 01:17:50 UTC
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.
Comment 35 Evert 2005-02-13 03:11:57 UTC
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
Comment 36 Fabian Groffen gentoo-dev 2005-02-13 03:20:17 UTC
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
Comment 37 Maurice van der Pot (RETIRED) gentoo-dev 2005-02-13 03:38:21 UTC
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

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:
Comment 38 Fabian Groffen gentoo-dev 2005-02-13 04:21:46 UTC
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.
Comment 39 Evert 2005-02-13 12:45:09 UTC
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 ;-)
Comment 40 Matthew Lane 2005-02-13 14:52:29 UTC
Hey.  I just want to say that r3 works perfectly on my system as well.
Comment 41 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2005-02-13 16:55:44 UTC
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).
Comment 42 Chris Monson 2005-02-14 08:40:44 UTC
Works great for me under AMD64.
Comment 43 Fabian Groffen gentoo-dev 2005-02-18 00:24:12 UTC
just a small update:

I haven't experienced any abnormalities with -r3 on my server.  It correctly unmounts and works like expected.
Comment 44 Fabian Groffen gentoo-dev 2005-04-13 00:59:55 UTC
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).
Comment 45 Evert 2005-04-13 11:45:28 UTC
r4 runs here already since march 21 without problems
Comment 46 Leho Kraav (:macmaN @lkraav) 2011-05-21 10:37:35 UTC
i'm pretty sure i'm seeing this with net-fs/autofs-5.0.4-r5.

May 21 13:31:36 travelmate automount[3262]: autofs stopped
May 21 13:32:00 travelmate automount[3385]: Starting automounter version 5.0.4, master map auto.master
May 21 13:32:00 travelmate automount[3385]: using kernel protocol version 5.02
May 21 13:32:00 travelmate automount[3385]: mounted indirect on /mnt with timeout 5, freq 2 seconds
May 21 13:32:00 travelmate automount[3385]: ghosting enabled

~ $ ls -l /mnt/usb

May 21 13:32:27 travelmate automount[3385]: attempting to mount entry /mnt/usb
May 21 13:32:27 travelmate kernel: [17494.593907] device label LAASU devid 1 transid 78 /dev/sdc1
May 21 13:32:27 travelmate automount[3385]: mount(generic): mounted /dev/sdc1 type auto on /mnt/usb
May 21 13:32:27 travelmate automount[3385]: mounted /mnt/usb
May 21 13:32:28 travelmate automount[3385]: 1 remaining in /mnt
May 21 13:32:30 travelmate automount[3385]: 1 remaining in /mnt
May 21 13:32:32 travelmate automount[3385]: 1 remaining in /mnt
May 21 13:32:34 travelmate automount[3385]: 1 remaining in /mnt
May 21 13:32:36 travelmate automount[3385]: 1 remaining in /mnt
May 21 13:32:38 travelmate automount[3385]: 1 remaining in /mnt
May 21 13:32:40 travelmate automount[3385]: 1 remaining in /mnt

i think it's pretty safe to say here my 5 second timeout isn't being honored. tips welcome while i continue debugging this.
Comment 47 Leho Kraav (:macmaN @lkraav) 2011-05-21 10:38:43 UTC
running x86

# uname -a
Linux travelmate #14 ZEN SMP PREEMPT Mon May 16 14:29:03 EEST 2011 i686 Intel(R) Core(TM) i3 CPU U 330 @ 1.20GHz GenuineIntel GNU/Linux
Comment 48 Leho Kraav (:macmaN @lkraav) 2011-05-21 11:08:25 UTC
USR1 does nothing for me, even though man says it's supposed umount all.

$ sudo killall -i -USR1 automount
Signal automount(3385) ? (y/N) y

mounts are still there. debug log seems to indicate that absolutely no action is taken.

May 21 13:50:56 travelmate automount[4406]: 2 remaining in /mnt
May 21 13:50:56 travelmate automount[4406]: expire_cleanup: got thid 3066968944 path /mnt stat 5
May 21 13:50:56 travelmate automount[4406]: expire_cleanup: sigchld: exp 3066968944 finished, switching from 2 to 1
May 21 13:50:56 travelmate automount[4406]: st_ready: st_ready(): state = 2 path /mnt
May 21 13:50:56 travelmate automount[4406]: do_notify_state: signal 10
May 21 13:50:56 travelmate automount[4406]: master_notify_state_change: sig 10 switching /mnt from 1 to 3
May 21 13:50:56 travelmate automount[4406]: st_prune: state 1 path /mnt
May 21 13:50:56 travelmate automount[4406]: expire_proc: exp_proc = 3066968944 path /mnt
May 21 13:50:56 travelmate automount[4406]: expire_proc_indirect: expire /mnt/gentoo
May 21 13:50:56 travelmate automount[4406]: expire_proc_indirect: expire /mnt/usb
May 21 13:50:56 travelmate automount[4406]: 2 remaining in /mnt

going to downgrade to autofs-4.1.3-r7 to test.
Comment 49 Leho Kraav (:macmaN @lkraav) 2011-05-21 12:23:49 UTC
autofs-4.1.3-r7 behaves better. nfs volumes get umounted on timeout. vfat usb stick also got umounted.

but a btrfs usb hard drive does not get umounted. there is nothing accessing it since doing "sudo umount /mnt/usb" umounts it just fine. "/etc/init.d/autofs stop" also fails on autofs-4.1.3-r7, when btrfs usb hard drive is attached.