Re: apt-get can not remount /usr ro. How to use lsof to find the offending files?
On 22/12/99 Shaul Karl wrote:
Let me see if I got it correctly:
mount can tell whether I have open file descriptors that are related to
removed files and there for it does not let me remount the fs ro?
What does it care? Will remounting the fs erase the data from these blocks?
Why was I allowed to remount /usr rw when apt-get was started?
the blocks have to be erased BEFORE the fs is remounted read only,
since a read only fs cannot be modified in any way (otherwise it
would not really be read only) you are allowed to remount it
read-write as long as its not read only due to hardware (ie cdrom)
but you can only remount it read only again as long as there are no
pending writes or a file is open with write permission. programs do
not open themselves with write permission however. (only a
braindamaged software would try and modify itself)
BTW: After I sent my previous email I tried to convince mount to let me
remount the fs ro by quitting some applications and then changing to run level
3 and then back to 2, which did not help. But then I stopped my mgetty-fax
daemon, and this enabled me the to mount the fs ro. I restarted the daemon
after wards. As far as I remember no megtty package was involved in the
upgrade, although it seems to be using some perl stuff and perl was indeed
upgraded. I wonder if others can verify that the meggty-fax daemon in
particular, or perhaps perl is responsible for not letting mount to remount
/usr ro after an upgrade. Can it be that it some how this daemon opens a file
rw but this is ignored when the fs is mounted ro?
no that is not possble, the kernel will not allow such a call to
succeed, if mgetty-fax was overwritten when it was still running the
old copy was not removed from disk, but its link count went to zero,
as soon as the file descripter is released then the blocks are freed.
I got a message in private from the author or lsof, it turns out
there is a way to show files of this nature:
At 10:14 -0500 22/12/99, Vic Abell wrote:
The +L option to lsof will help. It tells lsof to display the link
count for open files. A file that has been rm'd has a link count
of 0.
If you want, you can specify an integer afer +L and lsof will only
display open files whose link count is less than the integer. So,
for example, to find all unlinked open files:
$ lsof +L1
that should work to show exactly what is being the problem and let
you restart the offenders without the drastic telinit 1
--
Ethan Benson
To obtain my PGP key: http://www.alaska.net/~erbenson/pgp/
Reply to: