On Thu, Jul 21, 2011 at 01:03:52PM -0800, Jeff Spaleta wrote:
On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak(a)redhat.com>
>> really that is exactly what you want to do on your system. If our
>> mount command will still attempt to write to /etc/mtab once its a real
>> file again, maybe things will work for you as expected.
> No. systemd is not compatible with /etc/mtab
To be clear, you are saying that systemd won't be updating /etc/mtab
like the mount command tries to do?
(and maybe some others reports)
Just for completely I've done some more historical searches and
seeing this argument between mtab and /proc/*/mounts going all the
way back to 2000. And in all of the historic discussion I've seen
relying on ./proc/*/mount has been the recommendation due to it being
a canonical representation of what the mount points actually are at
any given point in time.
Sure, /etc/mtab is broken by design, because
* Linux uses namespaces - you can unshare part of VFS with the rest of
* only kernel has all information (typical problem is 'rw' in mtab
for read-only exported NFS)
* bind mounts are represented as /A -> /B dependence, reality is
/A -> device, /B -> device (and /A could be umounted, moved, ...)
* mount(2) is syscall, nobody is forced to use mount(8) util
* remount with options from mtab is problem if the options don't match
with real FS mount options used by kernel
* /etc/mtab~ lock is badly designed (proper fix means that you have to
fix *all* /sbin/mount.<type> helpers)
* /etc/mtab~ lock is performance problem (real issue for large
systems with autofs)
* use /etc for lock files and frequently updated files is really bad
idea (again, almost unfixable, real issue for read-only root fs)
* you need root permissions to update the file
Do you have a complete listing somewhere of the info thekernel does
not encode into /proc/mounts that mount has traditionally encodes into
/etc/mtab that existing tools might be making use of?
* userspace mount(8) specific mount options (e.g. user=, uhelper=),
libmount stores these options to the *private* /run/mount/utab file.
* NFS uses also libmount to store some extra information in userspace
I'm pretty sure based on everything I've read its not just
mount info, but also perhaps user or group info concerning who has
permission to mount and umount? Moving foward such a list would
probably help mitigate frustration and give admins a starting point
to adjusting their site specific configs.
I know only about the problem with 'df'.
Karel Zak <kzak(a)redhat.com>