Bug 214891 - mount: move mtab locks somewhere else
mount: move mtab locks somewhere else
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: util-linux-ng (Show other bugs)
12
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
: Triaged
: 359621 (view as bug list)
Depends On:
Blocks: K12LTSP 487604 THINCLIENT
  Show dependency treegraph
 
Reported: 2006-11-09 16:29 EST by Mark McLoughlin
Modified: 2013-01-09 23:07 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-20 04:35:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
util-linux-mtab-move-lock-files.patch (523 bytes, patch)
2006-11-09 16:29 EST, Mark McLoughlin
no flags Details | Diff
patch to move mtab locks (9.98 KB, patch)
2009-07-30 17:40 EDT, Karel Zak
no flags Details | Diff

  None (edit)
Description Mark McLoughlin 2006-11-09 16:29:15 EST
See bug #214877 for some context

If /etc/ is read-only, by /etc/mtab is bind-mounted to a tmpfs, then mount still
fails to update mtab because it can't create the lock file in /etc/

There's no sane way to work around this with e.g. /etc/rwtab, because we would
need to allow all of /etc/ to be writable since the lock file name uses the
processes pid.

Seems like the most obvious solution is to maintain these locks in /var/lock.
Trivial patch attached.
Comment 1 Mark McLoughlin 2006-11-09 16:29:15 EST
Created attachment 140838 [details]
util-linux-mtab-move-lock-files.patch
Comment 2 Karel Zak 2006-11-09 17:46:09 EST
Well, how will be the mount work with your patch if the /var will be different
filesystem? "mount /var" ?

I think all mount stuff must be at root filesystem only.
Comment 3 Karel Zak 2006-11-09 17:49:49 EST
... and it's not so easy. There is more programs that writes to /etc/mtab. You
have to change all of these utils (/sbin/[u]mount.[cifs|gfs|nfs|*], am-utils, ...).
Comment 4 Mark McLoughlin 2006-11-10 10:37:29 EST
(In reply to comment #2)
> Well, how will be the mount work with your patch if the /var will be different
> filesystem? "mount /var" ?

Hah. Point :)

In this case, though, /etc/mtab will be on a separate filesystem too. We just
mount it with -n, though

> I think all mount stuff must be at root filesystem only.

Except, we now support a read-only root filesystem

(In reply to comment #3)
> ... and it's not so easy. There is more programs that writes to /etc/mtab. You
> have to change all of these utils (/sbin/[u]mount.[cifs|gfs|nfs|*], am-utils, 
> ...).

Yep.
Comment 5 Jeff Law 2006-11-30 16:09:19 EST
We also need to figure out how to make sure all the utilities which care about
mtab~ locking are updated in lock-step with each other.  ie, it would be
extremely bad if some of the utilities were using /etc/mtab~ and others were
using /var/lock/mtab~.

Presumably this *can* be done with RPM.  Not being an RPM guru, I'm probably not
the best person to actually encode those changes into the spec files.

Jeff

Comment 6 Jeff Law 2006-12-11 13:16:18 EST
FYI -- /var/lock is part of the root filesystem as provided by the "filesystem"
RPM.  So really we just need to fix all the [u]mount utilities to move the lock
file into /var/lock and get the updates out in a synchronized manner.

Jeff
Comment 7 Jeff Law 2006-12-11 19:04:30 EST
FYI -- looks like the following need updating for moving the mtab lock file into
/var/lock:


/bin/[u]mount
/sbin/[u]mount.{cifs,gfs2,ncp,ncpfs,nfs,nfs4}
/usr/lib/ncp{map,mount,login,umount}
/usr/lib/libamu.so

/usr/libexec/hal-* puts a lock file in /media (ugh); however, given that /media
is going to need to be in /etc/rwtab anyway for hal storage bits to work at all,
it's something we don't need to fix today.

I didn't check anything in Fedora Extras, but I suspect we may need updates to
hfs, ntfs and maybe a couple other things.

In all it's not too terrible.

Jeff
Comment 8 Karel Zak 2008-01-23 08:51:28 EST
What's the current state of StatelessLinux?
Comment 9 Ian Dall 2008-02-18 17:04:26 EST
This is pretty much a show stopper for StatelessLinux. If mtab doesn't get
updated all kinds of bad things happen. mount -a results in things being mounted
twice possibly overlaying old mounts. If root gets mounted again it will be
mounted ro over all the bind mounts, effectively hiding them.
Comment 10 Jeff Law 2008-02-19 14:31:02 EST
I think we're better off throwing a union mount on top of /etc.  It resolves the
mtab problem and a few others.

I've been reasonably happy with the fuse based unionfs -- the only "big" problem
is it wants to update mtab when creating the union mount, which obviously
doesn't work (in fact, it hangs due to implementation details of FUSE).  The
FUSE guys were supposed to add a -n option to their mount program to suppress
mtab updates, but I haven't checked on it for a while (I'm currently on an
extended leave).

Jeff
Comment 11 Bug Zapper 2008-05-13 22:27:45 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Warren Togami 2008-08-04 15:19:01 EDT
*** Bug 359621 has been marked as a duplicate of this bug. ***
Comment 13 Warren Togami 2008-08-04 15:22:03 EDT
It seems that we are not getting anything like union mounts in Fedora any time soon.

Could priority on this be stepped up?
Comment 14 Ian Dall 2008-08-05 09:16:21 EDT
Moving locks to /var is definitely the clean solution, however, for what its worth, a viable work around is to make /etc/mtab a symbolic link to /proc/mounts  and always use the -n option to mount and unmount. This is definitely sub-optimal (mainly because you lose the record of some mount options) but it works for most things and is the only way I could make read-only root work acceptably.

I achieve the "always use -n" by replacing /bin/mount with a shell script which add the -n flag and execs the real mount program. It would be better if this was an fstab option, but it is only an interim approach anyway.
Comment 15 Karel Zak 2008-08-07 16:35:02 EDT
(In reply to comment #14)
> Moving locks to /var is definitely the clean solution, however, for what its

 Well, I'd like to see init scripts for the system where is mtab lock in /var/lock and the /var is separate FS.

> worth, a viable work around is to make /etc/mtab a symbolic link to
> /proc/mounts  and always use the -n option to mount and unmount. This is

 You needn't to use the -n option, because mount(8) is able to detect the mtab symlink.

> definitely sub-optimal (mainly because you lose the record of some mount
> options) but it works for most things and is the only way I could make

 I see two problems with the symlink:

  - user mounts (user= option)
  - bind mounts (/proc/mounts does not provide all relevant information
                 for umount(8))

 The mount(8) (since util-linux 2.14) and kernel (since v2.6.24) support auto-destruction of loop devices. It means we needn't to care about the loop= option any more.
Comment 16 Karel Zak 2008-08-07 16:40:51 EDT
(In reply to comment #13)
> It seems that we are not getting anything like union mounts in Fedora any time
> soon.

 *Unfortunately*. It would be nice to found and implement a global solution rather than deform tons of system utils.

 Why we cannot use a COW devices and write data to RAM disk (like LiveCD)?
Comment 17 Warren Togami 2008-12-18 01:23:00 EST
> You needn't to use the -n option, because mount(8) is able to detect the mtab
> symlink.

You are missing the point.  It is trying to create /etc/mtab.RANDOMSOMETHING which is impossible because /etc is writable, which is the entire point of wanting locks in another directory.

>  Why we cannot use a COW devices and write data to RAM disk (like LiveCD)?

It would be highly imprudent to dedicate that kind of RAM to a production system that relies on this.  Also dm-snap based tracking of changed blocks cannot 'whiteout' changes undone, so more activity there uses more and more RAM eventually leaded to a filesystem panic.  This has been a horrible hack for LiveCD to depend on.  The other distros do better than this with aufs or unionfs to get around this problem for both LiveCD and read-only root, but we cannot use them because they are unsuitable for the upstream kernel.

Adding to F11Blocker.
Comment 18 Karel Zak 2008-12-18 07:55:15 EST
(In reply to comment #17)
> > You needn't to use the -n option, because mount(8) is able to detect the mtab
> > symlink.
> 
> You are missing the point.  It is trying to create /etc/mtab.RANDOMSOMETHING
> which is impossible because /etc is writable, which is the entire point of
> wanting locks in another directory.

 mount(8) does not create any lock file when the mtab file is a symlink

 BTW, my plan for F11 is to move fstab and mtab code to libmount and use a global /etc/mount.conf where you can define a mtab directory.

 The long-term plan (F12) is to kill mtab file at all and use /proc/mounts and /proc/self/mountinfo only. (And /var/mount/ for some special userspace mount options.)
Comment 19 Steve Whitehouse 2008-12-18 08:32:03 EST
With regard to libmount, is there a git/cvs/svn repo somewhere, where its possible to watch this take shape?
Comment 20 Karel Zak 2008-12-18 09:12:13 EST
git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git

branch libmount, but there is nothing useful yet ... I need to found time and push some stuff there.
Comment 21 Brian J. Murrell 2009-02-27 09:34:47 EST
Using RHEL5.2 this still seems to be a problem, sadly.

Will any progress be made soon to clean this little mess up?
Comment 22 Bill Nottingham 2009-02-27 16:12:54 EST
*** Bug 487604 has been marked as a duplicate of this bug. ***
Comment 24 Jesse Keating 2009-04-13 20:30:16 EDT
This is entirely too late to introduce a change like this for F11.  Punting to F12.
Comment 25 Adam Williamson 2009-07-15 12:27:55 EDT
unless this is part of some kind of officially approved feature for f12, I'm not quite clear on how it can reasonably be considered as blocking the release?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Adam Williamson 2009-07-17 13:22:42 EDT
Discussed at critical bug review meeting. This is not critical for Fedora 12. If it's critical for a related RHEL project, please track that in the context of the RHEL project. Dropping from F12Blocker list. Thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 28 Karel Zak 2009-07-17 14:51:55 EDT
The libmount won't be ready for F-12/RHEL6, the back up plan is to move the lock files. 

I'm going to add some extra checks to the locking algorithm and probably /etc/mount.conf where you can define a directory for lock files (e.g. /var/lock).
Comment 29 Karel Zak 2009-07-27 17:29:40 EDT
Move mtab lock HOWTO:

  - install util-linux-ng >= 2.16-2.fc12
  - cp /usr/share/docs/util-linux-ng-2.16/mount.conf /etc
  - $EDITOR /etc/mount.conf (set MTAB_LOCK_DIR=)

Note that you need to use the same lock directory in all /sbin/mount.<type> utils. The default is still /etc.

The patch is fedora-specific. The upstream solution will be libmount and system without the mtab file. The /etc/mount.conf should be also supported by the library.
Comment 30 Warren Togami 2009-07-30 16:23:05 EDT
How do people feel about moving the locks to /dev by default?

/dev seems to be a good location because it is always read/write tmpfs, mounted by the initrd during bootup.

Any reason not to?  This should work nicely in all cases?
Comment 31 Warren Togami 2009-07-30 16:46:36 EDT
On second thought, perhaps we should remove this from mount.  This interim solution is incomplete because all the mount.* commands and fuse mounts that bypass /bin/mount do not respect the alternate mtab lock location.
Comment 32 Karel Zak 2009-07-30 17:33:51 EDT
I agree. It's really not simple task to fix this problem. It's seem that we need to kill mtab at all. Arbitrary other solution is hack.

The patch has been removed from the package.
Comment 33 Karel Zak 2009-07-30 17:40:04 EDT
Created attachment 355734 [details]
patch to move mtab locks

Just for the record, here is a patch that allows to move mtab locks. It could be useful for crazy people who don't care about /sbin/mount.<type> helpers and use mount(8) only.
Comment 34 Bug Zapper 2009-11-16 02:53:20 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 35 Karel Zak 2010-07-20 04:35:11 EDT
Closing, this issue has to be resolved by upstream (and upstream is working on this issue).
Comment 36 Alan Pevec 2010-07-20 08:33:08 EDT
(In reply to comment #35)
> (and upstream is working on this issue).

Is there upstream thread or git commit for which you can paste the link here?

Note You need to log in before you can comment on or make changes to this bug.