[gentoo-dev] Re: rfc: converting /etc/mtab to a symlink

[Steven J. Long]

On Mon, Oct 14, 2013 at 07:38:19AM +0800, Patrick Lauer wrote:
> On 10/14/2013 07:29 AM, Mike Gilbert wrote:
> > On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <patrick@g.o> wrote:
> >> On 10/14/2013 03:32 AM, William Hubbs wrote:
> >>> All,
> >>>
> >>> from what I'm seeing, we should look into converting /etc/mtab to a
> >>> symlink to /proc/self/mounts.
> >>>
> >>> Are there any remaining concerns about doing this?
> >>
> >> Apart from breaking umount -a and some other things?

What "other things"? AFAICT from the debian bug report[1] problems are far
much more likely when it's not a symlink, unless you're on kernel <2.6.26
(which is admittedly more likely for a Gentoo user, but it would not be the
mainstream Gentoo user, by any stretch of the imagination.)

> >> (The breakage is visible e.g. with umount -a tmpfs, which used to be
> >> quite useful if you had a few chroots with /var/tmp/portage as tmpfs and
> >> wanted to reset them. Now it'll also punt random things like /run if
> >> you're lucky - and in the past it knocked out the OpenRC state directory
> >> reliably)
> >>
> >
> > I don't follow this: it seems like umount -a is supposed to unmount
> > all filesystems. umount -a -t tmpfs would unmount all tmpfs
> > filesystems. /run should be included in that set, even if mtab is a
> > regular file.
> >
>
> And the magic trick is to keep "system mounts" like /run out of
> /etc/mtab (willful desynchronization) so that umount -a doesn't nuke
> them by accident.
>
> ... why else would you keep such data in two non-synchronized locations?! :D
>

You wouldn't: the only reason I've clung to the idea of a file, are the
transitional problems mentioned in the debian bug, ie information not available
in /proc/mounts that is available in /etc/mtab. Clearly that was fixed 2 years
ago, including for NFS and smb.

Given the CLONE_NEWNS issue (which one might use in the situation you describe):
"At this point, /etc/mtab *must* be a symlink to avoid breakage.  Note that
/proc/mounts is now a symlink to /proc/self/mounts for this reason: each process
has potentially different mounts"; going forward it really does not seem like a
good idea not to default to the symlink.

I agree it should not be forced on existing installs, nor on an admin who wants
to do something funky (or is using an ancient kernel for some reason.) However
I would definitely support a news item about the default change, along with
a recommendation for existing installs also to change, unless the admin has
a reason not to.

Just as a heads-up, that the ground has changed, and the vast majority really
do not want to be running without that symlink.

And yeah, script that properly (or a new namespace if it works) you lazy git ;p

Regards,
steveL.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494001

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)