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@xxxxxxxxxxxxx
Tel: +49 30 8413 1433
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
