ken@gvax.cs.cornell.edu (Ken Birman) (06/22/89)
From mailrus!uwmcsd4!Sun.COM!speed!gingell Thu Jun 22 03:57:56 1989 Received: from WRATH.CS.CORNELL.EDU by gvax.cs.cornell.edu (5.61+2/1.91d) id AA02328; Thu, 22 Jun 89 03:57:52 -0400 Received: by wrath.cs.cornell.edu (5.61+2/1.91d) id AA24143; Thu, 22 Jun 89 03:57:45 -0400 Received: by mailrus.cc.umich.edu (5.59/1.0) id AA23788; Thu, 22 Jun 89 03:51:22 EDT Received: by csd4.milw.wisc.edu; id AA25563; Thu, 22 Jun 89 02:51:46 -0500 Posted-Date: Thu, 22 Jun 89 00:11:19 PDT Received: from Sun.COM by cs.utexas.edu (5.59/36.2) id AA00385; Thu, 22 Jun 89 02:51:37 CDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03362; Thu, 22 Jun 89 00:09:39 PDT Received: from speed.sun.com (speed-ebb) by snail.Sun.COM (4.1/SMI-4.1) id AA07777; Thu, 22 Jun 89 00:08:12 PDT Received: from opus.sun.com by speed.sun.com (4.1/SMI-4.1) id AA02779; Thu, 22 Jun 89 00:11:20 PDT Date: Thu, 22 Jun 89 00:11:19 PDT From: mailrus!uwmcsd4!Sun.COM!speed!gingell (Rob Gingell) Message-Id: <8906220711.AA02779@speed.sun.com> Received: by opus.sun.com (4.1/SMI-4.1) id AA06018; Thu, 22 Jun 89 00:08:52 PDT To: mailrus!Sun.COM!sun-barr!cs.utexas.edu!csd4.milw.wisc.edu!mailrus!cornell!ken Subject: Re: A warning to SUN3/SUN4 users of SUN-OS 4.0.x Newsgroups: comp.sys.isis In-Reply-To: <29203@cornell.UUCP> Organization: Sun Microsystems, Mountain View Status: R In article <29203@cornell.UUCP> you write: >I just want to bring to people's attention a problem that we ran >into here at Cornell. On SUN OS 4.0.x the binary file from which >a program was loaded continues to be used AFTER the program starts >running, at least when you allow the dynamic linkage stuff to be >used (which is the default now for this release of SUN OS). If the binary is in the demand paged format, then pages from the binary that are needed during execution but not modified by the execution will be (re)obtained from the file throughout the life of the process. A demand-paged executable is just a mapped file to the system. >... This is not an ISIS problem, >but rather is a SUN "feature". All I can suggest is that you do >an "isis -Z" before installing a new version in a place you are running >ISIS out of. Hmm. It has been a common characteristic of UNIX implementations to implement code sharing via a data structure called the "text table". This mechanism for sharing couldn't really cope with someone modifying the things it was trying to share, so it prohibited it. This had the serendipitous effect of keeping people from overwriting running programs. However, this being UNIX, it was never the intent to "protect you from yourself" by not letting overwrite a program you were running -- it was a happenstance of the implementation of sharing. 4.0 does this differently, as will SVR4, and thus no more serendipity. As is UNIX' wont, you want to overwrite a file someone else is using -- it don't care. Note that pre-4.0 systems would have given you an error when you tried to link such programs. >If anyone know of something we should do in our makefile to prevent >this from happening, let me know. Does anyone know exactly what SUN OS >is doing? Is this tied to use of NFS somehow? You should use the "install" utility to install executables, rather than simply overwriting them with the compiler, when installing executables. "install" will permit processes running the program being re-"installed" to continue running out of the old copy, if done on the processor where such processes are executing. It has always been a characteristic of NFS, however, that if you modified a server file from some processor other than the client using a file, that the change would become apparent to the client in some random way.