Re: "Too many levels of symbolic links"

[Donald Buczek <buczek@molgen.mpg.de>]

Hi, Kent,

in 2014 we analyzed and discussed a problem which in my view boiled down 
to "autofs refuses to mount on a path (dentry) which already is mounted 
in another namespace." This is because it uses d_mountpoint ( = 
DCACHE_MOUNTED) to decide whether a mount should be attempted or not. At 
that point I selfishly changed our setting to avoid use of mount 
namespaces and left you alone with the problem.

But now we need mount namespaces ourselves using kernel 4.4.2 and the 
old problem reoccurred

So my questions:

* am I right, that this problem is still unresolved?
* is this considered a bug?

and if so, do you already have an idea, which way this could be resolved?

As a reminder, here is the script we used to demonstrate the problem ( 
assuming /project/mariux32 is served by autofs) :

===
#! /bin/sh

ls -ld /project/mariux32/.
unshare -m -- bash -c "sleep 6;ls -ld /project/mariux32/.;echo exit..." &
kill -USR1  `cat /var/run/autofs-running`
sleep 3
ls -ld /project/mariux32/.
wait
===

In your mail quoted below you wrote, the error would be avoided if "/" 
was set to shared before automount is started, but I can't confirm this.

===
root:nsa:/scratch/local/# systemctl stop automount.service
root:nsa:/scratch/local/# mount --make-rshared /
root:nsa:/scratch/local/# systemctl start automount.service
root:nsa:/scratch/local/# ./test.sh
drwxrwsr-x 6 mx32prj mx32grp 56 Feb 24  2011 /project/mariux32/.
ls: cannot access /project/mariux32/.: Too many levels of symbolic links
drwxrwsr-x 6 mx32prj mx32grp 56 Feb 24  2011 /project/mariux32/.
exit...
root:nsa:/scratch/local/#
===

Thank you!

   Donald


On 03/04/14 07:06, Ian Kent wrote:
> On Mon, 2014-03-03 at 10:40 +0800, Ian Kent wrote:
>>> That doesn't solve the problem, however, that mounts cloned by a
>>> unshare(CLONE_NEWNS) would never expire. Also there is another bug
>>> somewhere, because I see, that the mount, visible to the
>>> /usr/lib/colord/colord process was logged as "unmounted" in the nfs
>>> server when it expired in the global namespace. So I doubt it would be
>>> working even for that process. So possibly automounted mounts shouldn't
>>> be cloned at all? Together with chroot or pivot_root the sematics would
>>> be more than unclear anyway. Your problem now :-)
>> Hehe, like I said some people are going to be disappointed.
>>
>> There's just one question about this that remains.
>>
>> Assuming systemd is setting "/" shared what happens if "mount
>> --make-rprivate /" is run before autofs is started?
>>
>> So if you can spend a little more time on this an answer to this would
>> be helpful.
> No need for this, thanks to your reproducer.
>
> In fact the problem doesn't appear happen if "/" is set shared so in
> your case "/" must be set either slave or private.
>
> And expanding the reproducer a bit I see another failure case too, and
> it doesn't appear to be the unreliable d_mountpoint() check, not sure
> yet exactly what it is.
>
> Thanks
> Ian
>


-- 
Donald Buczek
buczek@molgen.mpg.de
Tel: +49 30 8413 1433

--
To unsubscribe from this list: send the line "unsubscribe autofs" in