[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Read-only /usr

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.

Yepp. The recent lsof has a modification to detect those files.

> 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.

Thats great :)

> 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.

Uh, and thats a crude solution :) We should better use the source to dpkg to
do that. Of course it would be even better if we are able to restart alll
processes, like we try to do on libc upgrade. This is not good for
production systems which should not have downtimes, but it is good for long
running systems cause the memory usage is better.

  (OO)      -- Bernd_Eckenfels@Wendelinusstrasse39.76646Bruchsal.de --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o     *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Reply to: