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. 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. 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 > > > > -- To unsubscribe from this list: send the line "unsubscribe autofs" in
