On 10.08.2012 12:33, Harald Dunkel wrote:
> Package: autofs5
> Version: 5.0.4-3.2+b1
>
> If /home/* is managed via autofs5, then quilt gets stuck
> when it tries to access /home/.pc .
>
>
> auto.master:
> /home /etc/auto.home
> /net -hosts
>
> auto.home:
> * -noatime nfs-home:/space/home/&
Ok.
> Sample session:
>
> % quilt --trace pop -a
[]
> +++ '[' -d .pc -o -d debian/patches ']'
> +++ basedir=/home/hdunkel/debian/nmap/tmp/nmap-6.00
> +++ '[' -n /home/hdunkel/debian/nmap/tmp/nmap-6.00 ']'
> +++ basedir=/home/hdunkel/debian/nmap/tmp
> +++ down=../
> +++ '[' -d /home/hdunkel/debian/nmap/tmp/.pc -o -d
> /home/hdunkel/debian/nmap/tmp/debian/patches ']'
> +++ '[' -n /home/hdunkel/debian/nmap/tmp ']'
> +++ basedir=/home/hdunkel/debian/nmap
> +++ down=../../
> +++ '[' -d /home/hdunkel/debian/nmap/.pc -o -d
> /home/hdunkel/debian/nmap/debian/patches ']'
> +++ '[' -n /home/hdunkel/debian/nmap ']'
> +++ basedir=/home/hdunkel/debian
> +++ down=../../../
> +++ '[' -d /home/hdunkel/debian/.pc -o -d /home/hdunkel/debian/debian/patches
> ']'
> +++ '[' -n /home/hdunkel/debian ']'
> +++ basedir=/home/hdunkel
> +++ down=../../../../
> +++ '[' -d /home/hdunkel/.pc -o -d /home/hdunkel/debian/patches ']'
> +++ '[' -n /home/hdunkel ']'
> +++ basedir=/home
> +++ down=../../../../../
> +++ '[' -d /home/.pc -o -d /home/debian/patches ']'
That's a good one.
> Thats it. I waited for 5 minutes. It seems that accessing
> /home/.pc gets stuck instead of returning a "No such file or
> directory". Needless to say that there are no users ".pc"
> or "debian".
Sure, this is wrong.
Can you please take a look at what is being done during these
5 minutes? Do a `ps afwx' at least, and see if there are
any `mount' commands spawned, etc.
The thing is: I can't reproduce it on my local environment.
I've one nfs server which exports a few dirs, I used this
map:
* -noatime gnome:/&
and wrote a tiny shell script:
--- cut ---
#! /bin/sh
x=$1
while [ "$x" != "" ]; do
if [ -d "$x/.pc" -o -d "$x/debian/patches" ]; then
echo "$x: .pc or debian/patches!"
fi
x=${x%/*}
done
--- cut ---
Session:
$ sh -x ./t /t/stage/tmp/album
+ x=/t/stage/tmp/album
+ [ /t/stage/tmp/album != ]
+ [ -d /t/stage/tmp/album/.pc -o -d /t/stage/tmp/album/debian/patches ]
+ x=/t/stage/tmp
+ [ /t/stage/tmp != ]
+ [ -d /t/stage/tmp/.pc -o -d /t/stage/tmp/debian/patches ]
+ x=/t/stage
+ [ /t/stage != ]
+ [ -d /t/stage/.pc -o -d /t/stage/debian/patches ]
+ x=/t
+ [ /t != ]
+ [ -d /t/.pc -o -d /t/debian/patches ]
+ x=
+ [ != ]
[exit]
it Just Works, without any delays whatsoever.
However I noticed that sometimes, regular mount.nfs hangs indefinitely
when trying to mount some non-accessible host or doing other bad
things. For example - just a wild guess! - nfs server may reject
".pc" as an invalid name and just drop the mount request, and the
client may not understand this and wait for the answer forever.
> Quilt is version 0.48-7. The user accounts are managed in
> nis 3.17-31. Please reassign if necessary.
Quilt version should not be interesting, it is just shell. NIS
should also be unrelated, but I'm not sure - it _looks_ like it
is not involved because of the direct map, it maps any name in
/home on the client stright to a directory on server.
Anyway.
Please - if you don't see any mount proceses hanging around --
first try to determine if executing the same test from the
shell (ie, no need to run quilt, just if [ -d /home/.pc ... ])
reproduces the issue. Next, enable debugging (-v -d options,
or LOGGING= in /etc/default/autofs), and see what it is doing
when this happens, ie, what automount is executing. I guess
it is just trying to call `mount' or `mount.nfs'. Do it
manually (maybe changing the destination directory to something
like /mnt to ensure it does not touch autofs) and see if that
hangs or what it produces. And so on.
I mean, since I can't reproduce this issue, there's very little
I can do, so I really need your help.
And this quilt habit to check for its files in every dir up
to the root directory is, well, wrong. But it does not make
this bug less important.
Thank you!
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
