On Sun, Nov 04, 2001 at 07:14:18PM +1000, Anthony Towns wrote: > > However this doesn't work quite frequently, since the umount fails > if there's any file in /usr that's been deleted (ie, was in a package > which has been updated), but is still being used (a /usr/lib/lib* that's > referenced by a long running program, or a /usr/bin/* program that's still > running, like apt-get or dselect). This is because the filesystem will > be modified when the file is closed, because the inode will be freed, > so it's obviously not read-only. > > That's the theory AIUI, anyway. thats presisly why. simplest way to deal with it is run lsof +L1 after an upgrade and kill/restart all offending processes. > To avoid this, we want to ensure that files aren't ever deleted after the > apt-get has finished. One way to do this is to keep a filename pointing > at all the inodes that can't be deleted. Unfortunately dpkg doesn't have > any hooks to do this. Fortunately, dpkg does. Two scripts are attached > which do this. > > Basically, one script is called after apt finishes downloading which > makes hard links for *all* files under /usr that'll be replaced over the > upcoming upgrade (keeping a note of all of them), and the other script > is called after every dpkg run, and, theoretically on reboot or similar, > which goes through that list and unlinks any files that it reasonably can. in which case you will have an increasing supply of cruft as time goes on? especially if reboots happen less then every 8 monthes. just IMO, but id rather just clean things up and kill offending processes then hide the problem. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpCi_AnqmUIN.pgp
Description: PGP signature