Messages in this thread | | | Date | Mon, 3 Nov 1997 21:35:23 +1100 | From | Richard Gooch <> | Subject | Re: File locking problems? |
| |
Matthias Urlichs writes: > Hi, > > > > Hi, all. I've had persistant problems with filesystems not being > >properly unmounted at shutdown. I've tracked it down to a corrupted > >/etc/mtab. > > Remove the locking code from mount and umount. > ln -s /proc/mtab /etc > ln -s /proc/mtab /var/run > > Bingo, the problem is gone.
If I do that then I a message about /dev/root not being mounted when I run shutdown. Furthermore, as the man page says, doing that will make working with the loop device less convenient.
> For an alternate solution see below. > > >These tests suggest that the fcntl(2) locking system is not working > >properly. Before I contemplate diving into the kernel code, is there > >anyone else out there who has experienced problems with fcntl(2), or > >knows about some bug? > > AFAIK, fcntl locking works. The problem is more likely to be with mount. > > For mount's style of locking to work properly, you need to do the following: > > lockit: > Create lock file if it doesn't exist > try to lock the file without blocking > if not successful: > print "Another mount process is running, waiting..." > lock with block (which should succeed after some time) > unlink lock file > close file, thereby removing the lock > goto lockit > write new data to lock file > rename mtab~ to mtab > close file, thereby removing the lock > > If you just try a normal lock on mtab~, which is what mount was doing last > time I looked, you can run into problems because by the time the blocking > process gets the lock on the lock file, it's not the lock file any more. > (Alternately, you can write new data to mtab.new and do the locking on > mtab~, but that's not optimal because you lose the message.)
But, as I said, I disabled the code in mount which removes the /etc/mtab~ lockfile. This means that the fcntl() locking will always work on the same file. Or is there some other effect going on?
Regards,
Richard....
| |