Re: "Too many levels of symbolic links"

[Ian Kent <raven@themaw.net>]

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