On Fri, 2020-01-31 at 13:34 +0800, Ian Kent wrote: > On Fri, 2020-01-31 at 01:09 +0100, Marc Lehmann wrote: > > On Thu, Jan 30, 2020 at 11:50:32PM +0000, Mike Gabriel < > > sunwea...@debian.org> wrote: > > > This seems like something to be discussed upstream. I Cc:ed Ian > > > Kent, maybe > > > he has some 2? to add. > > > > Cool! > > > > In the meantime, I digged a bit more, and it seems that it is > > because > > with > > misc-device support, autofs uses the AUTOFS_DEV_IOCTL_ISMOUNTPOINT > > ioctl > > to check whether something is a mountpoint, which returns 1, which > > causes > > the code in umount_multi to decude it cannot be symlink and > > unmounting it. > > > > Indeed, rm /dev/autofs before starting autofs makes it partially > > work > > (the > > target dir is not unmounted, but the entry is still gone without > > ghosting). > > > > Upstream probably already knows this, of course. > > Upstream doesn't know about this, ;) > > The behaviour is not correct and needs to be fixed. > > Sounds like I have enough information to duplicate the problem so > I'll have a look see.
A quick test with the current Fedora autofs package, autofs-5.1.5- 10.fc30.x86_64, I see that at expire the symlink is removed but the mount point directory used for browsing isn't recreated. I'll need to fix that. IIUC, the other aspect of this problem is that the target of the symlink, the NFSv4 mount, is also umounted at expire. That doesn't happen with the above Fedora package. This could get a bit complicated since there have been kernel changes as well as user space changes to the symlink handling with later version of autofs, we will need to work that out as we go. Can you confirm this second part of the problem occurs with the Debian package your using please, then we can hunt for patches from later autofs releases. Ian
