From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 21B161381F3 for ; Mon, 14 Oct 2013 01:33:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BDEA5E0968; Mon, 14 Oct 2013 01:33:47 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id CB542E08E0 for ; Mon, 14 Oct 2013 01:33:46 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.93,488,1378854000"; d="scan'208";a="37246587" Received: from unknown (HELO rathaus.eclipse.co.uk) ([109.176.215.102]) by smtpout.karoo.kcom.com with ESMTP; 14 Oct 2013 02:33:29 +0100 Date: Mon, 14 Oct 2013 02:40:26 +0100 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: rfc: converting /etc/mtab to a symlink Message-ID: <20131014014026.GA2828@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20131013193232.GA10488@linux1> <525B2B0B.8010404@gentoo.org> <525B2EEB.1080103@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <525B2EEB.1080103@gentoo.org> X-Archives-Salt: c55a62a4-2c8f-4c81-8e2d-9574f31c1063 X-Archives-Hash: 93d578ba6670ed91d550b4bb08dfbdf3 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 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 ;-)