> 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]#
