v2.29 plan: kill mtab

v2.29 plan: kill mtab

[Karel Zak]

libmount supports three scenarios:

 1) regular classic /etc/mtab

 2) /etc/mtab symlink to /proc/self/mount -- in this case libmount uses
    /proc/self/mountinfo and /run/mount/utab

 The current default is to detect symlink and on-the-fly switch
 between 1) and 2).

 3) --enable-libmount-force-mountinfo -- don't care about the symlink and 
    always use /proc/self/mountinfo. This is robust solution required
    for example by systemd, because unfortunately sometimes people use
    broken stuff (init scripts, tools, etc.) which removes the symlink.


 I'd like to make 3) default, the question is what with mtab code:
 
    a) #ifdef all mtab code (and add --enable-libmount-support-mtab)

    b) remove mtab support at all (because it's evil and horrible code)

 Comments?

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.29 plan: kill mtab

[Ruediger Meier]

On Thursday 07 April 2016, Karel Zak wrote:
> libmount supports three scenarios:
>
>  1) regular classic /etc/mtab
>
>  2) /etc/mtab symlink to /proc/self/mount -- in this case libmount
> uses /proc/self/mountinfo and /run/mount/utab
>
>  The current default is to detect symlink and on-the-fly switch
>  between 1) and 2).
>
>  3) --enable-libmount-force-mountinfo -- don't care about the symlink
> and always use /proc/self/mountinfo. This is robust solution required
> for example by systemd, because unfortunately sometimes people use
> broken stuff (init scripts, tools, etc.) which removes the symlink.
>
>
>  I'd like to make 3) default, the question is what with mtab code:
>
>     a) #ifdef all mtab code (and add --enable-support-mtab)
>
>     b) remove mtab support at all (because it's evil and horrible
> code)
>
>  Comments?

Even if b) is the final goal I would first do a) and mark the new 
option --enable-support-mtab as deprecated from the beginning.

Could be interesting to see who would ever use this option and because 
of which reasons.

About changing the default: We could add a warning somewhere to a 
non-critical tool when printing human-readable output, like lsblk:
  "warning: deprecated /etc/mtab file ingnored"

... just to remind people to fix their system/scripts.

cu,
Rudi

unrecognized options: --without-capng

[Marcus Hoffmann]

Dear all,
in experimenting a bit with configure options I found the
--without-capng option (as reported by configure --help) giving the
following warning (and having no effect):
> configure: WARNING: unrecognized options: --without-capng

Looking into configure.ac I found the option should probably be named
--without-cap_ng (AC_ARG_WITH([cap_ng],...).

But using this the configure script dies with the following message:

> configure: error: conditional "HAVE_CAP_NG" was never defined.
> Usually this means the macro was only invoked conditionally.

--without-cap-ng produces the same result.

I tried fiddling around with the autoconf macros but got no further than
that.

Marcus

Re: unrecognized options: --without-capng

[Mike Frysinger]

[-- Attachment #1.1: Type: text/plain, Size: 1635 bytes --]

On 07 Apr 2016 16:00, Marcus Hoffmann wrote:
> Dear all,
> in experimenting a bit with configure options I found the
> --without-capng option (as reported by configure --help) giving the
> following warning (and having no effect):
> > configure: WARNING: unrecognized options: --without-capng
> 
> Looking into configure.ac I found the option should probably be named
> --without-cap_ng (AC_ARG_WITH([cap_ng],...).

yes, the help string is wrong.  it should be:
--- a/configure.ac
+++ b/configure.ac
@@ -1182,7 +1182,7 @@ AC_CHECK_FUNCS([setns])
 
 
 AC_ARG_WITH([cap_ng],
-  AS_HELP_STRING([--without-capng], [compile without libcap-ng]),
+  AS_HELP_STRING([--without-cap-ng], [compile without libcap-ng]),
   [], [with_cap_ng=auto]
 )
 AS_IF([test "x$with_cap_ng" = xno], [have_cap_ng=no],[

> But using this the configure script dies with the following message:
> 
> > configure: error: conditional "HAVE_CAP_NG" was never defined.
> > Usually this means the macro was only invoked conditionally.
> 
> --without-cap-ng produces the same result.
> 
> I tried fiddling around with the autoconf macros but got no further than
> that.

the helper macros can sometimes obscure things

--- a/configure.ac
+++ b/configure.ac
@@ -1189,7 +1189,10 @@ AC_ARG_WITH([cap_ng],
   AS_HELP_STRING([--without-capng], [compile without libcap-ng]),
   [], [with_cap_ng=auto]
 )
-AS_IF([test "x$with_cap_ng" = xno], [have_cap_ng=no],[
+AS_IF([test "x$with_cap_ng" = xno], [
+  AM_CONDITIONAL([HAVE_CAP_NG], [false])
+  have_cap_ng=no
+],[
   UL_CHECK_LIB([cap-ng], [capng_apply], [cap_ng])
 ])
 
-mike

[-- Attachment #1.2: conf.patch --]
[-- Type: text/x-diff, Size: 952 bytes --]

From 110c2c94c59742e9879f2f39e6aec79925dc1592 Mon Sep 17 00:00:00 2001
From: Mike Frysinger <vapier@gentoo.org>
Date: Thu, 7 Apr 2016 12:17:43 -0400
Subject: [PATCH] build-sys: fix cap-ng configure flag handling

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 configure.ac | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index e42a2c4..9e0e28b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1186,10 +1186,13 @@ AC_CHECK_FUNCS([setns])
 
 
 AC_ARG_WITH([cap_ng],
-  AS_HELP_STRING([--without-capng], [compile without libcap-ng]),
+  AS_HELP_STRING([--without-cap-ng], [compile without libcap-ng]),
   [], [with_cap_ng=auto]
 )
-AS_IF([test "x$with_cap_ng" = xno], [have_cap_ng=no],[
+AS_IF([test "x$with_cap_ng" = xno], [
+  AM_CONDITIONAL([HAVE_CAP_NG], [false])
+  have_cap_ng=no
+],[
   UL_CHECK_LIB([cap-ng], [capng_apply], [cap_ng])
 ])
 
-- 
2.7.4


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: unrecognized options: --without-capng

[Karel Zak]

On Thu, Apr 07, 2016 at 12:18:02PM -0400, Mike Frysinger wrote:
>  configure.ac | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Applied, thanks.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.29 plan: kill mtab

[Ruediger Meier]

On Thursday 07 April 2016, Karel Zak wrote:
> libmount supports three scenarios:
>
>  1) regular classic /etc/mtab
>
>  2) /etc/mtab symlink to /proc/self/mount -- in this case libmount
> uses /proc/self/mountinfo and /run/mount/utab
>
>  The current default is to detect symlink and on-the-fly switch
>  between 1) and 2).
>
>  3) --enable-libmount-force-mountinfo -- don't care about the symlink
> and always use /proc/self/mountinfo. This is robust solution required
> for example by systemd, because unfortunately sometimes people use
> broken stuff (init scripts, tools, etc.) which removes the symlink.
>
>
>  I'd like to make 3) default, the question is what with mtab code:
>
>     a) #ifdef all mtab code (and add --enable-libmount-support-mtab)
>
>     b) remove mtab support at all (because it's evil and horrible
> code)
>
>  Comments?
>
>     Karel


What about this first step:

>From e6c17f35a8d63f129c5bbd722995b97d050e4151 Mon Sep 17 00:00:00 2001
From: Ruediger Meier <ruediger.meier@ga-group.nl>
Date: Wed, 13 Apr 2016 22:33:06 +0200
Subject: [PATCH] libmount: deprecate /etc/mtab file

Default is now --enable-libmount-force-mountinfo.

Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 31a1911..e4e6996 100644
--- a/configure.ac
+++ b/configure.ac
@@ -958,8 +958,8 @@ AC_SUBST([LIBMOUNT_VERSION_INFO])
 AC_DEFINE_UNQUOTED([LIBMOUNT_VERSION], ["$LIBMOUNT_VERSION"], [libmount version string])

 AC_ARG_ENABLE([libmount-force-mountinfo],
-  AS_HELP_STRING([--enable-libmount-force-mountinfo], [ignore /etc/mtab in all situations (recommended for systemd)]),
-  [], [enable_libmount_force_mountinfo=no]
+  AS_HELP_STRING([--disable-libmount-force-mountinfo], [use deprecated /etc/mtab file (not recommended and incompatible with openrc or systemd)]),
+  [], [enable_libmount_force_mountinfo=yes]
 )

 AS_IF([test "x$enable_libmount_force_mountinfo" == xyes], [
--
1.8.4.5

Re: v2.29 plan: kill mtab

[Karel Zak]

On Wed, Apr 13, 2016 at 10:58:28PM +0200, Ruediger Meier wrote:
> On Thursday 07 April 2016, Karel Zak wrote:
> > libmount supports three scenarios:
> >
> >  1) regular classic /etc/mtab
> >
> >  2) /etc/mtab symlink to /proc/self/mount -- in this case libmount
> > uses /proc/self/mountinfo and /run/mount/utab
> >
> >  The current default is to detect symlink and on-the-fly switch
> >  between 1) and 2).
> >
> >  3) --enable-libmount-force-mountinfo -- don't care about the symlink
> > and always use /proc/self/mountinfo. This is robust solution required
> > for example by systemd, because unfortunately sometimes people use
> > broken stuff (init scripts, tools, etc.) which removes the symlink.
> >
> >
> >  I'd like to make 3) default, the question is what with mtab code:
> >
> >     a) #ifdef all mtab code (and add --enable-libmount-support-mtab)
> >
> >     b) remove mtab support at all (because it's evil and horrible
> > code)
> >
> >  Comments?
> >
> >     Karel
> 
> 
> What about this first step:

I have applied another patch to disable mtab by default, a new 
configure option

    --enable-libmount-support-mtab 
    
is necessary to enable the original behavior.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.29 plan: kill mtab

[Robby Workman]

Karel Zak wrote:

> libmount supports three scenarios:
> 
> 1) regular classic /etc/mtab
>
> 2) /etc/mtab symlink to /proc/self/mount -- in this case libmount uses
>    /proc/self/mountinfo and /run/mount/utab
>
> The current default is to detect symlink and on-the-fly switch
> between 1) and 2).
>
> 3) --enable-libmount-force-mountinfo -- don't care about the symlink
>    and always use /proc/self/mountinfo. This is robust solution required
>    for example by systemd, because unfortunately sometimes people use
>    broken stuff (init scripts, tools, etc.) which removes the symlink.
>
>
> I'd like to make 3) default, the question is what with mtab code:
>
>    a) #ifdef all mtab code (and add --enable-libmount-support-mtab)
>
>    b) remove mtab support at all (because it's evil and horrible code)
>
> Comments?


We still use SysV init because it suits our needs just fine, and we
have no plans to migrate to systemd in the foreseeable future, so
we don't have any other compelling reason to use anything other than
classic /etc/mtab. As such, we'd certainly appreciate, at the very
least, leaving the mtab support in util-linux.

-RW

Re: v2.29 plan: kill mtab

[Karel Zak]

On Sun, Apr 10, 2016 at 09:35:41PM -0700, Robby Workman wrote:
> Karel Zak wrote:
> 
> > libmount supports three scenarios:
> > 
> > 1) regular classic /etc/mtab
> > 
> > 2) /etc/mtab symlink to /proc/self/mount -- in this case libmount uses
> >    /proc/self/mountinfo and /run/mount/utab
> > 
> > The current default is to detect symlink and on-the-fly switch
> > between 1) and 2).
> > 
> > 3) --enable-libmount-force-mountinfo -- don't care about the symlink
> >    and always use /proc/self/mountinfo. This is robust solution required
> >    for example by systemd, because unfortunately sometimes people use
> >    broken stuff (init scripts, tools, etc.) which removes the symlink.
> > 
> > 
> > I'd like to make 3) default, the question is what with mtab code:
> > 
> >    a) #ifdef all mtab code (and add --enable-libmount-support-mtab)
> > 
> >    b) remove mtab support at all (because it's evil and horrible code)
> > 
> > Comments?
> 
> 
> We still use SysV init because it suits our needs just fine, and we
> have no plans to migrate to systemd in the foreseeable future, so
> we don't have any other compelling reason to use anything other than
> classic /etc/mtab. As such, we'd certainly appreciate, at the very
> least, leaving the mtab support in util-linux.

This discussion is really not about init, but about mtab that is
broken by design. 

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.29 plan: kill mtab

[Robby Workman]

On Mon, 11 Apr 2016, Karel Zak wrote:

> On Sun, Apr 10, 2016 at 09:35:41PM -0700, Robby Workman wrote:
>> Karel Zak wrote:
>>
>>> libmount supports three scenarios:
>>>
>>> 1) regular classic /etc/mtab
>>>
>>> 2) /etc/mtab symlink to /proc/self/mount -- in this case libmount uses
>>>    /proc/self/mountinfo and /run/mount/utab
>>>
>>> The current default is to detect symlink and on-the-fly switch
>>> between 1) and 2).
>>>
>>> 3) --enable-libmount-force-mountinfo -- don't care about the symlink
>>>    and always use /proc/self/mountinfo. This is robust solution required
>>>    for example by systemd, because unfortunately sometimes people use
>>>    broken stuff (init scripts, tools, etc.) which removes the symlink.
>>>
>>>
>>> I'd like to make 3) default, the question is what with mtab code:
>>>
>>>    a) #ifdef all mtab code (and add --enable-libmount-support-mtab)
>>>
>>>    b) remove mtab support at all (because it's evil and horrible code)
>>>
>>> Comments?
>>
>>
>> We still use SysV init because it suits our needs just fine, and we
>> have no plans to migrate to systemd in the foreseeable future, so
>> we don't have any other compelling reason to use anything other than
>> classic /etc/mtab. As such, we'd certainly appreciate, at the very
>> least, leaving the mtab support in util-linux.
>
> This discussion is really not about init, but about mtab that is
> broken by design.


Okay, then how about this? Our current use of /etc/mtab works well
for us, and as far as I'm aware, we've experienced absolutely
none of this "[breakage] by design" - as such, we'd be grealy
appreciative if the option remains to continue using it.

-RW

Re: v2.29 plan: kill mtab

[Karel Zak]

On Tue, Apr 12, 2016 at 07:33:08PM -0700, Robby Workman wrote:
> > This discussion is really not about init, but about mtab that is
> > broken by design.
> 
> Okay, then how about this? Our current use of /etc/mtab works well

btw, mount(8) supports /etc/mtab -> /proc/mounts symlink for 20
years...

> for us, and as far as I'm aware, we've experienced absolutely
> none of this "[breakage] by design" - as such, we'd be grealy
> appreciative if the option remains to continue using it.

We're trying to be friendly to all Linux users ...so we're going to
#ifdef mtab stuff and keep --enable-libmount-support-mtab there for
the next years to keep you happy.

Maybe one day you will enter wonderful 21 century where we have 
Linux namespaces, containers, bind mounts, mount move operation,
chroots, btrfs, NFS and another cool stuff... and then you will see
that there is a fundamental difference between "what kernel thinks
about VFS" and "how users call mount(8)".

Fair enough?
    
   Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: v2.29 plan: kill mtab

[Ruediger Meier]

On Wednesday 13 April 2016, Robby Workman wrote:
> On Mon, 11 Apr 2016, Karel Zak wrote:
> > On Sun, Apr 10, 2016 at 09:35:41PM -0700, Robby Workman wrote:
> >> Karel Zak wrote:
> >>> libmount supports three scenarios:
> >>>
> >>> 1) regular classic /etc/mtab
> >>>
> >>> 2) /etc/mtab symlink to /proc/self/mount -- in this case libmount
> >>> uses /proc/self/mountinfo and /run/mount/utab
> >>>
> >>> The current default is to detect symlink and on-the-fly switch
> >>> between 1) and 2).
> >>>
> >>> 3) --enable-libmount-force-mountinfo -- don't care about the
> >>> symlink and always use /proc/self/mountinfo. This is robust
> >>> solution required for example by systemd, because unfortunately
> >>> sometimes people use broken stuff (init scripts, tools, etc.)
> >>> which removes the symlink.
> >>>
> >>>
> >>> I'd like to make 3) default, the question is what with mtab code:
> >>>
> >>>    a) #ifdef all mtab code (and add
> >>> --enable-libmount-support-mtab)
> >>>
> >>>    b) remove mtab support at all (because it's evil and horrible
> >>> code)
> >>>
> >>> Comments?
> >>
> >> We still use SysV init because it suits our needs just fine, and
> >> we have no plans to migrate to systemd in the foreseeable future,
> >> so we don't have any other compelling reason to use anything other
> >> than classic /etc/mtab. As such, we'd certainly appreciate, at the
> >> very least, leaving the mtab support in util-linux.
> >
> > This discussion is really not about init, but about mtab that is
> > broken by design.
>
> Okay, then how about this? Our current use of /etc/mtab works well
> for us, and as far as I'm aware, we've experienced absolutely
> none of this "[breakage] by design"

AFAIR we've had a lot of /etc/mtab related bugs in past, for sure also 
reproducable on Slackware. For util-linux upstream it's annyoing to fix 
these bugs by adding ugly code ... although there is a rock-solid 
replacement available since many years.

> - as such, we'd be grealy 
> appreciative if the option remains to continue using it.

There are many advantages by using /proc and unfixable issues 
with /etc/mtab file. IMHO in this case you should have a real reason 
why you don't want to go forward.

> -RW
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v2.29 plan: kill mtab

[Isaac Dunham]

On Sun, Apr 10, 2016 at 09:35:41PM -0700, Robby Workman wrote:
> Karel Zak wrote:
> 
> > libmount supports three scenarios:
> > 
> > 1) regular classic /etc/mtab
> > 
> > 2) /etc/mtab symlink to /proc/self/mount -- in this case libmount uses
> >    /proc/self/mountinfo and /run/mount/utab
> > 
> > The current default is to detect symlink and on-the-fly switch
> > between 1) and 2).
> > 
> > 3) --enable-libmount-force-mountinfo -- don't care about the symlink
> >    and always use /proc/self/mountinfo. This is robust solution required
> >    for example by systemd, because unfortunately sometimes people use
> >    broken stuff (init scripts, tools, etc.) which removes the symlink.
> > 
> > 
> > I'd like to make 3) default, the question is what with mtab code:
> > 
> >    a) #ifdef all mtab code (and add --enable-libmount-support-mtab)
> > 
> >    b) remove mtab support at all (because it's evil and horrible code)
> > 
> > Comments?
> 
> 
> We still use SysV init because it suits our needs just fine, and we
> have no plans to migrate to systemd in the foreseeable future, so
> we don't have any other compelling reason to use anything other than
> classic /etc/mtab. As such, we'd certainly appreciate, at the very
> least, leaving the mtab support in util-linux.

Contrary to the implication of the mail you quote, whether to use mtab
is not primarily about systemd. Alpine Linux, the distro I use, uses
the /proc/mounts symlink; the userspace is Busybox/OpenRC with musl libc.

The main reason to use /proc/self/mountinfo is that it can be relied on
to tell you what filesystems are mounted where, even if you use chroots,
mount namespaces, private mounts, and similar things. This is because
the kernel necessarily needs to keep track of mounts on a per-process
basis. 
mtab can get confused by chroots and bind mounts, because /etc/mtab
is the userspace keeping track, manually, of the same information,
based on the assumptions that it's the only toolset doing mounts and
unmounts, that everything has the same mounts, and so on; essentially,
it's like keeping track of the number of people in a room by watching
who goes in or out.
Why would you bother counting people going through the door if you have
a window?
Why use code that poorly duplicates information the kernel *needs* to
have an accurate record of?



Thanks,
Isaac Dunham