[lug] NSLU2

[Zan Lynx]

On Sat, 2006-02-11 at 17:34 -0700, David L. Anselmi wrote:
> So that reminds me of a question.  At work on Solaris 8, if we use cp to 
> update a library used by a running app the app will crash.  So we're 
> told to make sure we use rdist.  How does Linux handle this and is there 
> a better way?
> 
> The difference is that cp opens the file and overwrites the contents 
> while rdist unlinks the file and links to the new file.  With cp, 
> running apps will see the changes as they are executing (edit a running 
> bash script with vi and see what happens).  With rdist, running apps 
> keep their references and are oblivious to the new files until they are 
> restarted (or do a new open, which is usually ok).
> 
> The thing is that I'm not aware of Linux packages doing any special 
> handling to prevent problems when upgrading.  They may stop network 
> servers first, and restart them after.  But libc gets upgraded 
> regardless that KDE, mozilla, and whatever are running during the 
> upgrade.  I guess I'm not completely sure what happens with rpms or 
> debs, but make install usually just copies things.
> 
> Anyone know the details of this or do I have to do my own research?

Linux package managers use link/unlink, and/or rename to do all file
replacements.  RPM creates the new files with names sort of like
"/lib/libc-2.3.6.so;2344323" and then renames them into place after they
have all been written with temporary names.  By doing this, RPM gets as
close as it can to an atomic update of all files at once, and you never
end up with it running out of disk space with half updated packages.
Although it does require having twice the actually needed disk space
available.

I don't know all the details of apt/dpkg, but it must do something
similar.
-- 
Zan Lynx <zlynx at acm.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20060213/7614c970/attachment.pgp>