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
>
Can it be that the removed files are not the problem with the failure of the remounting?
[04:17:04 /tmp]# mount -o remount,ro /usr/
mount: /usr is busy
[04:19:08 /tmp]# lsof +L1 |grep /usr/
[04:19:16 /tmp]#
Reply to: