As you probably aware of, having a ro /usr and trying to remount it ro
after apt-get upgrade sometimes fails because the device or resource is
busy.
I heard a possible explanation for this behavior and I was looking for
other people comments. It can be that I don't understand some or all of
the details. The explanation I heard goes like this:
Basically, when one removes a binary file from a UNIX file system, it
is gone - no matter if this binary is currently in use. Therefore,
assuming this binary is larger then one page of memory, as soon as the
system will have to load other pages of the binary into main memory in
order to be able to run other parts of the code it will fail to find it.
In particular, the fact that one had just removed that binary should not
get in the way of umounting the file system that the file containing that
binary was in. However there is an exception for this rule and this is
the one that we see with apt-get. The exception is that the system might
still holds in the buffer cache some of the inodes of that binary file.
One can see this buffer cache in the last column of the mem raw of top.
If this is the case then the system does see that something is wrong: it
has inodes that belong to the file system that we are trying to umount.
And thus we get the device or resource is busy message.
Please note that although this might sound as a homework exercise, it
is not. It is just an attempt to understand the behavior of a Debian
system. debian-devel had a thread about it a year or so ago, although
that thread also suggested a way to reveal the offending files (with
lsof) and IIRC, a workaround too. It could be that that thread contained
the explanation I am looking for. If it did I couldn't understand it.
Hopefully other people will find it worth the bandwidth too.
--
Shaul Karl, [EMAIL PROTECTED] e t
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
