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....