Remove the locking code from mount and umount.
ln -s /proc/mtab /etc
ln -s /proc/mtab /var/run
Bingo, the problem is gone.
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.)
The above algorithm is stolen from INND+CNFS's locking of its overview
files. I'm running four of those processes concurrently all the time and a
check right now didn't find any missing or corrupted entries.
-- Matthias Urlichs noris network GmbH