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.
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
The mount point still shows up, no matter how long you wait.
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-220.127.116.1140808-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
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/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
ftp://mirror.pudas.net/gentoo http://gentoo.ccccom.com ftp://gentoo.ccccom.com"
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:
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: 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).
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:
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).
set the timeout value for automount to a ridiculous low value in /etc/conf.d/autofs, like:
# /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: 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).
Downgrading to the masked '=autofs-4.1.3' FIXED the problem.
(I use udev if that makes any difference.)
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
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
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
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:
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
i'm pretty sure i'm seeing this with net-fs/autofs-5.0.4-r5.
May 21 13:31:36 travelmate automount: autofs stopped
May 21 13:32:00 travelmate automount: Starting automounter version 5.0.4, master map auto.master
May 21 13:32:00 travelmate automount: using kernel protocol version 5.02
May 21 13:32:00 travelmate automount: mounted indirect on /mnt with timeout 5, freq 2 seconds
May 21 13:32:00 travelmate automount: ghosting enabled
~ $ ls -l /mnt/usb
May 21 13:32:27 travelmate automount: 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: mount(generic): mounted /dev/sdc1 type auto on /mnt/usb
May 21 13:32:27 travelmate automount: mounted /mnt/usb
May 21 13:32:28 travelmate automount: 1 remaining in /mnt
May 21 13:32:30 travelmate automount: 1 remaining in /mnt
May 21 13:32:32 travelmate automount: 1 remaining in /mnt
May 21 13:32:34 travelmate automount: 1 remaining in /mnt
May 21 13:32:36 travelmate automount: 1 remaining in /mnt
May 21 13:32:38 travelmate automount: 1 remaining in /mnt
May 21 13:32:40 travelmate automount: 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.
# uname -a
Linux travelmate 18.104.22.168-zen+ #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
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: 2 remaining in /mnt
May 21 13:50:56 travelmate automount: expire_cleanup: got thid 3066968944 path /mnt stat 5
May 21 13:50:56 travelmate automount: expire_cleanup: sigchld: exp 3066968944 finished, switching from 2 to 1
May 21 13:50:56 travelmate automount: st_ready: st_ready(): state = 2 path /mnt
May 21 13:50:56 travelmate automount: do_notify_state: signal 10
May 21 13:50:56 travelmate automount: master_notify_state_change: sig 10 switching /mnt from 1 to 3
May 21 13:50:56 travelmate automount: st_prune: state 1 path /mnt
May 21 13:50:56 travelmate automount: expire_proc: exp_proc = 3066968944 path /mnt
May 21 13:50:56 travelmate automount: expire_proc_indirect: expire /mnt/gentoo
May 21 13:50:56 travelmate automount: expire_proc_indirect: expire /mnt/usb
May 21 13:50:56 travelmate automount: 2 remaining in /mnt
going to downgrade to autofs-4.1.3-r7 to test.
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.