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 <patr...@gentoo.org> 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 ;-)
