Re: "Too many levels of symbolic links"

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

On 03/16/16 03:10, Ian Kent wrote:
> On Wed, 2016-03-09 at 18:44 +0100, Donald Buczek wrote:
>> 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/#
>> ===
> Actually, assuming /project is an indirect mount, I think that should
> have been OK.

My fault. It does work. I've overlooked

 > unshare  since  util-linux  version  2.27  automatically  sets 
propagation to private in a
 > new mount namespace to make sure that the new namespace is really
 > unshared.  It's possible to disable this feature with option 
--propagation unchanged.

So in fact it does

 > unshare(CLONE_NEWNS)                    = 0
 > mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL) = 0

If I add "--propagation unchanged" to the test script, it works. Might 
be a solution for our environment.

I understand, that the combined semantics of automount and mount 
namespaces are yet to be defined and there is no clear,unique way to do 
that.

But independent of that, I think it might be better if autofs would 
continue to try to mount on top of a dentry with DCACHE_MOUNTED set and 
this might be a requirement for most of the thinkable solutions.

> Again, there's more going on, probably unshare not cloning file handles
> (the -m clones only the mount namespace I think). Without a way of
> sending mount requests to the automount daemon, which needs to be done
> via a file handle (the current pipe implementation or even if it was
> socket based) the symptom will be the same as when / is propagation
> private.

Well, with "mount --make-rshared /" and "unshare -m --propagation 
unchanged" it looks like everything seems to be working. And the mounts 
can be triggered from the new namespace as well. There is only one 
cosmetic thing: When a automount expires, the unmount fails when the 
(shared mount) in the other namespace still is busy. This generates some 
log.

2016-05-20T15:43:39+02:00 deadbird automount[938]: expiring path 
/project/mariux32
2016-05-20T15:43:39+02:00 deadbird automount[938]: >> umount.nfs: 
/project/mariux32: device is busy
2016-05-20T15:43:39+02:00 deadbird automount[938]: >> umount.nfs: 
/project/mariux32: device is busy
2016-05-20T15:43:39+02:00 deadbird automount[938]: >> umount.nfs: 
/project/mariux32: device is busy
2016-05-20T15:43:39+02:00 deadbird automount[938]: Unable to update the 
mtab file, /proc/mounts and /etc/mtab will differ
2016-05-20T15:43:39+02:00 deadbird automount[938]: expired /project/mariux32

Regards
   Donald


>
> This is just a guess though.
>
>> 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