rfc: converting /etc/mtab to a symlink

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

rfc: converting /etc/mtab to a symlink

William Hubbs
All,

from what I'm seeing, we should look into converting /etc/mtab to a
symlink to /proc/self/mounts [1].

Are there any remaining concerns about doing this?

If not, it seems like it would be pretty easy to make baselayout create
this symlink in the stages (I'm willing to do this work), but what about
on systems that are already installed? Should we send out a news item
and have everyone convert their /etc/mtab manually or find a way to
automate that?

William

[1] http://bugs.gentoo.org/show_bug.cgi?id=477498

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Matt Turner-5
On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <[hidden email]> wrote:

> All,
>
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?
>
> William
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

Is the issue with NFS user mounts resolved? (Mentioned
https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Patrick Lauer
In reply to this post by William Hubbs
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 [1].
>
> Are there any remaining concerns about doing this?

Apart from breaking umount -a and some other things?
None at all ;)

(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)

There are pretty good historical reasons for having /etc/mtab as a file,
maybe you should do some archeology before just trying to change things.

Applications that can't handle a properly set up Linux system should be
patched to either use /proc/mounts unconditionally or randomly segfault
to emulate proper Windows best practises.

>
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?

... you automate that, you get a few angry bugs.
Better to warn, if you absolutely have to, and let users consciously
remove features when they are ready for it.

Thanks,

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Mike Gilbert-2
On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <[hidden email]> 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 [1].
>>
>> Are there any remaining concerns about doing this?
>
> Apart from breaking umount -a and some other things?
> None at all ;)
>
> (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.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Patrick Lauer
On 10/14/2013 07:29 AM, Mike Gilbert wrote:

> On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <[hidden email]> 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 [1].
>>>
>>> Are there any remaining concerns about doing this?
>>
>> Apart from breaking umount -a and some other things?
>> None at all ;)
>>
>> (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

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
On Sun, Oct 13, 2013 at 7:38 PM, Patrick Lauer <[hidden email]> wrote:
> 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
>

Sounds interesting and all, but I don't think this really should be
driving our system design (the desire to have a command that is
supposed to unmount everything not actually unmount everything).  It
wouldn't take more than a few lines of bash to just write a script to
unmount the stuff you're interested in - I routinely toss in my
chroots a script to mount/unmount stuff (tmpfs, bind-mounts, proc/sys,
etc).

There could very well be other issues with changing mtab to a symlink
though, so continue to speak up if there are other things that could
go wrong.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Mike Gilbert-2
In reply to this post by Patrick Lauer
On Sun, Oct 13, 2013 at 7:38 PM, Patrick Lauer <[hidden email]> wrote:

> On 10/14/2013 07:29 AM, Mike Gilbert wrote:
>> On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer <[hidden email]> 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 [1].
>>>>
>>>> Are there any remaining concerns about doing this?
>>>
>>> Apart from breaking umount -a and some other things?
>>> None at all ;)
>>>
>>> (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
>

That's certainly a neat trick. However, it seems a bit weird to use a
system-wide database for such a use case; what if multiple users are
setting up mounts like this?

I guess the key takeaway from this is that people do unconventional
things. Probably best to just change the default, and throw up a big
warning for existing users as you indicated in your original reply.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Mike Gilbert-2
In reply to this post by Matt Turner-5
On Sun, Oct 13, 2013 at 5:13 PM, Matt Turner <[hidden email]> wrote:

> On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <[hidden email]> wrote:
>> All,
>>
>> from what I'm seeing, we should look into converting /etc/mtab to a
>> symlink to /proc/self/mounts [1].
>>
>> Are there any remaining concerns about doing this?
>>
>> If not, it seems like it would be pretty easy to make baselayout create
>> this symlink in the stages (I'm willing to do this work), but what about
>> on systems that are already installed? Should we send out a news item
>> and have everyone convert their /etc/mtab manually or find a way to
>> automate that?
>>
>> William
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498
>
> Is the issue with NFS user mounts resolved? (Mentioned
> https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)
>

Could someone using NFS actually test and see if there are any
problems? That comment on the wiki has no details, and Google has not
been very helpful in finding an answer.

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

William Hubbs
In reply to this post by Patrick Lauer
On Mon, Oct 14, 2013 at 07:21:47AM +0800, 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 [1].
> >
> > Are there any remaining concerns about doing this?
>
> Apart from breaking umount -a and some other things?
> None at all ;)
>
> (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)
>
> There are pretty good historical reasons for having /etc/mtab as a file,
> maybe you should do some archeology before just trying to change things.
and maybe you should think before you accuse. Coming to this list *is*
doing that archaeology. If I were going to change things without doing
that archaeology, I would just make the change happen without warning.

William

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Steven J. Long
In reply to this post by Patrick Lauer
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 <[hidden email]> 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 ;-)

yac
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

yac
In reply to this post by William Hubbs
AFAIK this known historical behavior that what you find in
`/etc/mtab` are things mounted by mount(8) (if that's what's printed by
running just mount).

Whereas /proc/mounts is the kernel view on what's mounted.

Curiously I don't see any difference on my gentoo box, which I think I
should see but I'm not sure.

Anyway, I've seen differences when eg. automounter was used, iirc.
I wouldn't be surprised if there are things that depends on this
behavior or if there are more cases like automounter.

On Sun, 13 Oct 2013 14:32:32 -0500
William Hubbs <[hidden email]> wrote:

> All,
>
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout
> create this symlink in the stages (I'm willing to do this work), but
> what about on systems that are already installed? Should we send out
> a news item and have everyone convert their /etc/mtab manually or
> find a way to automate that?
>
> William
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498


signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

pva0xd
In reply to this post by Matt Turner-5
В Вс, 13/10/2013 в 14:13 -0700, Matt Turner пишет:
> On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <[hidden email]> wrote:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].

> Is the issue with NFS user mounts resolved? (Mentioned
> https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)

Looks like Gentoo's nfs-utils package does not support this. nfs-utils
have --enable-libmount-mount so we just need to start using it.
https://bugs.gentoo.org/show_bug.cgi?id=487962

BTW, most distributions did all this changes two years ago, so all
packages have support for mtab. For exampled, I've checked two packages
that had this problem two years ago and one package unconditionally
depends on libmount (pam_mount) while another just avoids touch mtab if
it's not writable and works anyway (cifs-utils). Both packages with
required changes are in Gentoo's stable tree :)

--
Peter.


Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

pva0xd
In reply to this post by William Hubbs
В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?

The only concern I have how this change affects *BSD or prefix? But yet
I failed to find a package that is affected and that is not Linux
specific.

--
Peter.


Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Pacho Ramos
In reply to this post by pva0xd
El lun, 14-10-2013 a las 09:58 +0400, Peter Volkov escribió:

> В Вс, 13/10/2013 в 14:13 -0700, Matt Turner пишет:
> > On Sun, Oct 13, 2013 at 12:32 PM, William Hubbs <[hidden email]> wrote:
> > > from what I'm seeing, we should look into converting /etc/mtab to a
> > > symlink to /proc/self/mounts [1].
>
> > Is the issue with NFS user mounts resolved? (Mentioned
> > https://wiki.gentoo.org/wiki/Systemd#.2Fetc.2Fmtab and elsewhere)
>
> Looks like Gentoo's nfs-utils package does not support this. nfs-utils
> have --enable-libmount-mount so we just need to start using it.
> https://bugs.gentoo.org/show_bug.cgi?id=487962
>
> BTW, most distributions did all this changes two years ago, so all
> packages have support for mtab. For exampled, I've checked two packages
> that had this problem two years ago and one package unconditionally
> depends on libmount (pam_mount) while another just avoids touch mtab if
> it's not writable and works anyway (cifs-utils). Both packages with
> required changes are in Gentoo's stable tree :)
>
> --
> Peter.
>
>
>

Thanks for finding the problem with NFS :)


Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Fabian Groffen-2
In reply to this post by pva0xd
On 14-10-2013 10:00:03 +0400, Peter Volkov wrote:
> В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет:
> > from what I'm seeing, we should look into converting /etc/mtab to a
> > symlink to /proc/self/mounts [1].
> >
> > Are there any remaining concerns about doing this?
>
> The only concern I have how this change affects *BSD or prefix? But yet
> I failed to find a package that is affected and that is not Linux
> specific.

If it works for the host system, then Prefix should be fine.

Fabian

--
Fabian Groffen
Gentoo on a different level

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
In reply to this post by yac
On Mon, Oct 14, 2013 at 12:42 AM, yac <[hidden email]> wrote:
>
> Curiously I don't see any difference on my gentoo box, which I think I
> should see but I'm not sure.

On mine the main difference seems to be bind mounts.  In /etc/mtab the
bind mount "device" is the directory that is being bind-mounted.  In
/proc/self/mounts it is the device that the directory sits on.  Other
than a little confusion, I"m not sure if that will actually cause any
issues.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Ben de Groot-2
In reply to this post by William Hubbs
On 14 October 2013 03:32, William Hubbs <[hidden email]> wrote:

> All,
>
> from what I'm seeing, we should look into converting /etc/mtab to a
> symlink to /proc/self/mounts [1].
>
> Are there any remaining concerns about doing this?
>
> If not, it seems like it would be pretty easy to make baselayout create
> this symlink in the stages (I'm willing to do this work), but what about
> on systems that are already installed? Should we send out a news item
> and have everyone convert their /etc/mtab manually or find a way to
> automate that?
>
> William
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498

I don't see a compelling case being made for why we should make this
change apart from "all the other distros are doing it", and quite a
few reasons why we shouldn't. I'm open to being convinced, so please
tell me why this is good for Gentoo users.

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Rich Freeman
On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <[hidden email]> wrote:
> I don't see a compelling case being made for why we should make this
> change apart from "all the other distros are doing it", and quite a
> few reasons why we shouldn't. I'm open to being convinced, so please
> tell me why this is good for Gentoo users.

So far I've seen a reference to a bug associated with a bunch of
systemd issues when it isn't mounted, and the point that many things
break in namespaces without the symlink, since /etc/mtab does not
reflect the state of the namespace.  The latter in particular seems
like a pretty fundamental limitation - the very concept of /etc/mtab
is that mounts are global, and the design of linux is that mounts are
NOT global.

If all the other distros are doing it, there is probably a reason.

As far as problems with switching - I've only seen one or two
correctable issues that seem compelling (NFS issues, and PAM issues).
There was a bunch of talk about how making this change will cause a
command designed to unmount everything actually unmount everything as
well.

But please continue to chime in with both pros and cons.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
In reply to this post by Ben de Groot-2
That is my impression as well.

With that said, the behavior is currently the same between our FreeBSD and Linux variants. This change would break that.

On Oct 14, 2013, at 7:59 AM, Ben de Groot <[hidden email]> wrote:

> On 14 October 2013 03:32, William Hubbs <[hidden email]> wrote:
>> All,
>>
>> from what I'm seeing, we should look into converting /etc/mtab to a
>> symlink to /proc/self/mounts [1].
>>
>> Are there any remaining concerns about doing this?
>>
>> If not, it seems like it would be pretty easy to make baselayout create
>> this symlink in the stages (I'm willing to do this work), but what about
>> on systems that are already installed? Should we send out a news item
>> and have everyone convert their /etc/mtab manually or find a way to
>> automate that?
>>
>> William
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498
>
> I don't see a compelling case being made for why we should make this
> change apart from "all the other distros are doing it", and quite a
> few reasons why we shouldn't. I'm open to being convinced, so please
> tell me why this is good for Gentoo users.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
>

Reply | Threaded
Open this post in threaded view
|

Re: rfc: converting /etc/mtab to a symlink

Richard Yao-2
In reply to this post by Rich Freeman
On Oct 14, 2013, at 9:19 AM, Rich Freeman <[hidden email]> wrote:

> On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot <[hidden email]> wrote:
>> I don't see a compelling case being made for why we should make this
>> change apart from "all the other distros are doing it", and quite a
>> few reasons why we shouldn't. I'm open to being convinced, so please
>> tell me why this is good for Gentoo users.
>
> So far I've seen a reference to a bug associated with a bunch of
> systemd issues when it isn't mounted, and the point that many things
> break in namespaces without the symlink, since /etc/mtab does not
> reflect the state of the namespace.  The latter in particular seems
> like a pretty fundamental limitation - the very concept of /etc/mtab
> is that mounts are global, and the design of linux is that mounts are
> NOT global.

Why should this not be treated as a systemd bug?

> If all the other distros are doing it, there is probably a reason.

Perhaps they lack a FreeBSD variant and therefore see no reason to be different than Fedora.

> As far as problems with switching - I've only seen one or two
> correctable issues that seem compelling (NFS issues, and PAM issues).
> There was a bunch of talk about how making this change will cause a
> command designed to unmount everything actually unmount everything as
> well.

How do these corrections affect Gentoo FreeBSD?

12