Since util-linux-2.29 support of /etc/mtab being a regular file is off by default. Reproducible: Always Steps to Reproduce: 1. emerge util-linux >= 2.29 2. setup /etc/mtab as regular file 3. mount or unmount partition Actual Results: /etc/mtab is left unchanged Expected Results: /etc/mtab should change to reflect mountpoint changes
It works as expected with <sys-apps/util-linux-2.29. From https://www.kernel.org/pub/linux/utils/util-linux/v2.29/v2.29-ReleaseNotes: - don't support /etc/mtab by default [Karel Zak]
Please tell us why you need this. It is causing problems for systemd users and even OpenRC has switched to a symlink and now throws warnings if it is a regular file.
(In reply to Thomas Deutschmann from comment #2) > Please tell us why you need this. It is causing problems for systemd users > and even OpenRC has switched to a symlink and now throws warnings if it is a > regular file. Please tell me how does an OPTION to use /etc/mtab as regular file (in addition to option to use it as symlink) breaks systemd? This configure flag doesn't force you to use /etc/mtab as regular file, it just provides an option. And part about openrc is a lie. As I already responded on github, openrc supports /etc/mtab both as regular file and as symlinks, no warnings there, a supported configuration. Why I need it? It's simple, I need a functioning non-broken system, and it includes /etc/mtab being correct. Now on topic of problems caused by this issue. There's old bug in ktorrent where it worked really slow with NTFS filesystems: https://bugs.kde.org/show_bug.cgi?id=354633 It was fixed long ago, it uses some Qt stuff to find out info about destination filesystem, and if it's NTFS, then do some workaround that prevented freezes. Unfortunately, with /etc/mtab broken by new util-linux, it fails to discover that destination filesystem is NTFS and bug reappears.
(In reply to i.Dark_Templar from comment #3) > Please tell me how does an OPTION to use /etc/mtab as regular file (in > addition to option to use it as symlink) breaks systemd? This configure flag > doesn't force you to use /etc/mtab as regular file, it just provides an > option. See upstream's commit msg: https://github.com/karelzak/util-linux/commit/e778642a9eb96975fcf3baa61dfa10add628af1a > And part about openrc is a lie. As I already responded on github, openrc > supports /etc/mtab both as regular file and as symlinks, no warnings there, > a supported configuration. Yes, this was added later, https://github.com/OpenRC/openrc/commit/b29b2fb3cb3e73b4453483ced908f0ef10e47e9c We are not going to restore the old behavior and enable the option like you did in your PR. However, I'll mask it behind a USE flag so people who need this can re-enable...
(In reply to Thomas Deutschmann from comment #4) > (In reply to i.Dark_Templar from comment #3) > > Please tell me how does an OPTION to use /etc/mtab as regular file (in > > addition to option to use it as symlink) breaks systemd? This configure flag > > doesn't force you to use /etc/mtab as regular file, it just provides an > > option. > See upstream's commit msg: > > https://github.com/karelzak/util-linux/commit/ > e778642a9eb96975fcf3baa61dfa10add628af1a > Hmm, I've read commit message. It claims it's somehow dangerous to enable support of /etc/mtab as regular file, but it doesn't support the claim with any evidence. And the code looks good enough to support both modes of /etc/mtab. It's only danger is political, because it allows system configurations that are not systemd-based.
No, it is not political. See bug 477498 and friends. And many packages were updated in the meantime and are now expecting /proc/self/mounts content. So you will be on your own anyways. But like said, we will add a USE flag to restore old behavior for those who "needs" this.
(In reply to Thomas Deutschmann from comment #6) > No, it is not political. See bug 477498 and friends. And many packages were > updated in the meantime and are now expecting /proc/self/mounts content. So > you will be on your own anyways. But like said, we will add a USE flag to > restore old behavior for those who "needs" this. I still don't see any evidence that enabling option to have /etc/mtab either as symlink OR as regular file breaks systemd if it's still a symlink. I've looked up a bug you mentioned, and it's only about systemd being broken in there IF /etc/mtab is not a symlink. I didn't see any other broken stuff there being mentioned. And no mention of systemd breaking if util-linux just allows /etc/mtab being a regular file (but doesn't force it being one). It's just systemd being broken by using /etc/mtab when /etc/mtab is regular file while systemd really needs to just use /proc/self/mounts and don't touch /etc/mtab, and breaking everything else instead of fixing systemd. On the other hand I see this feature forcefully turned off and breaking /etc/mtab on purpose in favor of systemd-driven setup. So yes, it is just political.
Actually it isn't. The problem is, /etc/mtab is flawed in its original design, for two reasons. First, mounts aren't system wide, they are process specific. That is why software should be looking at /proc/self/mounts instead of /etc/mtab. The second issue is, suppose you want / to be read-only. If that is the case, there are issues with /etc/mtab.
One more concern is in relation to mount namespaces. You cannot create a separate mount namespace if you have /etc/mtab as a file.
(In reply to William Hubbs from comment #8) > Actually it isn't. > > The problem is, /etc/mtab is flawed in its original design, for two > reasons. > > First, mounts aren't system wide, they are process specific. That is why > software should be looking at /proc/self/mounts instead of /etc/mtab. > > The second issue is, suppose you want / to be read-only. If that is the > case, there are issues with /etc/mtab. I've never seen a system where part of it has different mountpoints. Unless you consider containers being a part of same system. I consider containers being a separate systems running inside current system. Like virtual machine, but lighter and probably more risky in terms of security, some form of advanced chroot. Your virtual machines don't share /etc/mtab with your host one, and your chroots too, right? I'd gladly learn about such system setups with different mounts for it's parts if I missed something. If / is readonly, you certainly may do a lot of stuff to work around this issue, including not mounting anything so that your /etc/mtab remains valid, or bind-mounting it to read-write or symlinking it somewhere. You do something with /etc/resolv.conf in that case, right? And there are probably some other configs requiring being writable too. And main point is, if you want /proc/self/mounts, you already have it, why are you using /etc/mtab? And if you don't mount /proc, you don't have a valid /etc/mtab now, do you? I don't mind people using /etc/mtab as symlink to /proc/self/mounts, but please don't break setup with /etc/mtab being a regular file. (In reply to William Hubbs from comment #9) > One more concern is in relation to mount namespaces. You cannot create a > separate mount namespace if you have /etc/mtab as a file. Could you please tell me more about that? I have /etc/mtab as file and I don't see any issues related to mounting when I'm running lxc.
https://xkcd.com/1172/
The issue is that, for a long time, /etc/mtab has been kept around as a compatibility symlink to /proc/self/mounts since they need to be kept in sync. Having it as a file creates two separate lists of mounts which are not kept in sync. I'm not trying to troll, just asking an honest question. What is breaking if /etc/mtab is a file instead of a symlink to /proc/self/mounts? If it is just mount/umount, it is probably time to do this: # ln -snf /proc/self/mounts /etc/mtab and re-configure /etc/init.d/mtab to make sure it stays a symlink. If some other software is breaking, I would definitely like to know what it is. OpenRC itself doesn't really care, it uses /proc/self/mounts everywhere. You should read NEWS.md for OpenRC, in particular, the section for openrc 0.18.3.
Nothing breaks if /etc/mtab is a symlink as far as I know, and same way nothing breaks if it's a file. Unless you break it on purpose, like it's done at the moment. So it's a matter of preferences. A matter of politics. Does something break if you migrate to systemd? Probably not. Why don't you then? By the way, if you use /etc/mtab as file and do a bind mount, /etc/mtab and /proc/self/mounts have a very different contents for that mount point. I have in my /etc/fstab a record similar to: /some/path1 /some/path2/bound none defaults,bind,nofail 0 0 where /some/path1 is located on /dev/sda1 and /some/path2/bound on /dev/sdb1, for example. Here's what in /etc/mtab for that mountpoint: /some/path1 /some/path2/bound none rw,bind 0 0 Here's what in /proc/self/mounts for that mountpoint: /dev/sda1 /some/path2/bound fuseblk rw,noatime,data=ordered 0 0 where rw,noatime,data=ordered - mount options of /dev/sda1. Those two files contain different information, and while usually /proc/self/mounts has more accurate information, sometimes it's other way around.
After discussing with the OpenRC team and base-system project we came to the conclusion that we will reject your change request. We will not add an USE flag to toggle "--enable-libmount-support-mtab" (however, I'll add support for EXTRA_ECONF to the ebuild). The OpenRC team is planning on removing the mtab service in the future. Q: Why are we going to do that? A: Because we do not see any reason to support both. Keep in mind: If we would support both implementations, we would have to test everything with just "/etc/mtab" and "/etc/mtab -> /proc/self/mounts". But we don't have the man power to do that. So until anyone can show us a real _technical_ reason to keep supporting old traditional "/etc/mtab" (and just showing us that content of "/etc/mtab" doesn't match content of "/proc/self/mounts" isn't enough -- you need to show us a real example where this will cause problems/loss of functionality) we will proceed. So this is your call: If you can show us a real problem caused by "/etc/mtab -> /proc/self/mounts" which would require us to keep traditional "/etc/mtab" support do that _now_ because we don't want to break your system. But keep in mind: Just saying "No! I just don't want to adapt any changes in general" is no _technical_ reason...
