Mark_H_Johnson.RTS@raytheon.com wrote:
>
> On this issue [updates to active files...] how does the typical distribution
> update process handle this? For example, if I'm doing a package update using a
> typical tool [gnoRPM, kpackage, etc.] what is happening behind the scenes to
> prevent disaster? The situation where I've booted from CD-ROM & doing a major
> distribution update would be safe doing a simple replacement. OTOH, if I get an
> "urgent" patch that I need to apply, must I track down all the jobs that are
> currently using the files being updated, get them stopped, do the update, and
> then restart them to be "safe"? [and I'll quit doing the "dangerous" updates
> that I've been doing through ignorance] If so, is that going to kill the use of
> Linux in high availability situations [or must I run redundant systems to work
> around this]?
>
Well, the executable is loaded into memory once started. For the most
part, you can overwrite the executable (or other file) on the disk, as
long as you have permissions to do so. So, no, you don't have to track
down all the other processes and stop them, in order to replace the file
on disk. Be careful, though, with things like your libc. If you
overwrite *that* with an invalid version, you're pretty much screwed,
without a rescue disk set.
Other operating systems, AFAIK, implement an operating-system level
locking mechanism, whereby the OS locks the file and won't let it be
overwritten. On Linux (and Unix in general, I guess), there are a
couple of different types of lock, and if you have a program which
performs, say, a partial file lock, you cannot be guaranteed that that
lock will be respected--unless and until every application written
implements the same type of locking and also checks to see if a file is
locked before doing something to it.
> On 4 May 2000, Trond Myklebust wrote:
>
> >Not good. If I'm running /bin/bash, and somebody on the server updates
> >/bin/bash, then I don't want to reboot my machine. With the above
>
You wouldn't have to reboot. Why would you think you need to reboot?
This isn't Winbloze, for god's sake. All it means is that new bash
processes will use the updated version, while old processes would still
be using the old version--it's loaded in memory, remember? Hell, you
can even overwrite the libc on a running system.
> If you use rename(2) to update the shell (as you should since `cp` would
> corrupt also users that are reading /bin/bash from local fs) then nfs
> should get it right also with my patch since it should notice the inode
> number changed (the nfs fd handle should get the inode number as cookie),
> right?
My understanding of rename(2) is that it only returns EBUSY on
directories, and not on individual files. BTW, I don't see the message
this was in reference to on lkml--what was your patch?
-- Matthew Vanecek Visit my Website at http://mysite.directlink.net/linuxguy For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something...- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:16 EST