Your message dated Fri, 8 Jun 2012 13:04:03 +1000
with message-id
<CANBdODXoxSBAgLqVtEMAUhAghXtUmJ=tuOu_=_Kk+Jj=0ub...@mail.gmail.com>
and subject line Bug#349073: fixed in autofs 5.0.6-2
has caused the Debian Bug report #349073,
regarding autofs: automount directors go away and are inaccessible till reboot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
349073: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349073
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: autofs
Version: 4.1.4-8
Severity: important
For many months now, automount forgets mountpoints shortly after using
them for the first time. They then become inaccessible. Example:
$ cd /fs/doom_localvol4
This works. Leaving that directory and waiting for some time creates this
situation:
$ cd /fs/doom_localvol4
cd: /fs/doom_localvol4: No such file or directory
$ ls -l /fs
drwxr-xr-x 31 root root 4096 Jan 19 21:50 doom
drwxr-xr-x 11 root root 312 Dec 2 20:23 doom_localvol
drwxr-xr-x 12 root root 360 Dec 2 20:24 doom_localvol3
drwxr-xr-x 3 root root 53 Jan 20 10:45 doom_localvol4
$ mount
<no trace of /fs/doom_localvol4, same in /proc/mounts>
During the first cd, automount might log something like the following:
Jan 20 21:07:21 cerebro automount[17613]: failed to mount /fs/doom_localvol4
With no extra message. Manually entering:
$ mount doom:/localvol4 /fs/doom_localvol4
Works fine and makes the directory accessible again.
It is _possible_ that my typical use makes this more apparent: I
never access /fs/doom_localvol4 directly, but always a path like
/fs/doom/dir/blabla. Some of the components are symlinks that point to
/fs/doom_mountpoint/xxx.
e.g. cd /fs/doom/var/lib/mythtv actually ends up in
/fs/doom_localvol4/var/lib/mythtv/.
This happens mostly regardless of kernel version (happens with every
kernel from 2.6.8 to 2.6.15.1 on both amd64 and x86 servers _and_
clients).
Somehow the directories become unmounted but do not go away and this seems
to cause problems.
automount is started like this:
automount -p /var/run/automount.pid /fs file /etc/maps/fs
And the relevant sections of /etc/maps/fs is:
doom -intr,rsize=8192,wsize=8192 doom:/
doom_localvol -intr,rsize=8192,wsize=8192 doom:/localvol
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15.1
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages autofs depends on:
hi libc6 2.3.5-12 GNU C Library: Shared libraries an
ii ucf 2.004 Update Configuration File: preserv
Versions of packages autofs recommends:
ii nfs-common 1:1.0.7-3 NFS support files common to client
-- debconf information:
autofs/upgrade-from-broken-version:
--- End Message ---
--- Begin Message ---
Source: autofs
Source-Version: 5.0.6-2
We believe that the bug you reported is fixed in the latest version of
autofs, which is installed in the Debian FTP archive.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
--- End Message ---
