Re: Remote upgrade possible?
On Jan 7, 2005, at 12:33 PM, Danny MacMillan wrote: I haven't looked at the code, but your assertion is extremely unlikely. I really want to say "impossible" but as I said, I haven't looked at the code. If FreeBSD loaded entire executable images into RAM when starting new processes, it would perform very poorly. What is more likely is that the kernel keeps the image file open during program execution. When the xterm binary is replaced, the old binary is still on disk in its old location, it just doesn't have any directory entries pointing to it. Since the kernel still has the file open it won't be overwritten. Hence the kernel can and will still load pages from the old image. This is a function of the same behaviour that causes df and du output to differ in some cases. The lsof(8) utility seems to bear this out, as each process seems to keep each image (program and shared object files) open during execution. A new instance of xterm would use the new, upgraded binary. When you run a program the program that runs the new one makes a copy of itself in the process table and they share code pages. This is done through fork(). At that point the new process, called the child, calls one of the exec() function calls which in turn calls a single syscall, execve(). execve() uses namei() to get the vnode pointer. Each vnode pointer has three ference counts, v_usecount, v_holdcnt and v_writecount. A vnode is not recycled until both the usecount and holdcnt are 0. When namei() is called it calls VREF() which is vref() which does vp->v_usecount++; so if it's running the page can't be recycled from a point in time before the program actually is loaded in to memory. execve() calls exec_map_first_page(). Without tearing this apart I'm going to guess that this memory maps the first page of text (code) through the VM subsystem as evidenced by the conspicuous calls to vm_page*() functions so I'd conclude the file is memory mapped. Presuming it turns out the command you're calling isn't a shell script or other script execve() cleans up the environment so file descriptors and signal handlers don't get shared, the processes environment is setup, lets the calling (forking) process know it can continue on it's merry way, sets uid/gid if necessary/possible, and it looks like the scheduler takes care of the rest (I'll be honest here, the code seems to trail off here so far as I can tell in to parts that are jumped to in case of error). In any case we have a increased usecount. Now we are going to unlink that file and create a new one. After some basic checks (you can't remove the root of a file system for example) unlink() will call VOP_REMOVE() which calls vrele() which deincrements the usecount when it's greater than one, which in this case it MUST be because the xterm process has one count on it and the file entry has another (hard links to the file may have additional counts on it). Therefore it appears that you can unlink the file, it will remain on the disk to serve the memory mapped image used for the running process and install a new copy. I'm going to presume when a process exits it de-increments the usecount for the vnode, which, when 0 should put the page on the free list. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remote upgrade possible?
On Fri, Jan 07, 2005 at 07:25:02AM -0500, Mike Jeays wrote: > On Thu, 2005-01-06 at 23:26, Tabor Kelly wrote: > > > > I routinely use 'portupgrade -rRN' in xterm, in X-Windows to > > install new ports on my box. The second to last time I did this, > > one of the ports what was upgraded was xterm. And it worked! Can > > anybody explain to my why nothing bad happened? Am I running a > > risk when I do this? > > This seems pretty safe to me. When xterm gets invoked, the whole of the > code gets loaded into memory for execution, and there is no reason why > it would look at the disk copy again. If you upgrade the xterm binary, I haven't looked at the code, but your assertion is extremely unlikely. I really want to say "impossible" but as I said, I haven't looked at the code. If FreeBSD loaded entire executable images into RAM when starting new processes, it would perform very poorly. What is more likely is that the kernel keeps the image file open during program execution. When the xterm binary is replaced, the old binary is still on disk in its old location, it just doesn't have any directory entries pointing to it. Since the kernel still has the file open it won't be overwritten. Hence the kernel can and will still load pages from the old image. This is a function of the same behaviour that causes df and du output to differ in some cases. The lsof(8) utility seems to bear this out, as each process seems to keep each image (program and shared object files) open during execution. A new instance of xterm would use the new, upgraded binary. -- Danny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remote upgrade possible?
On Thu, 2005-01-06 at 23:26, Tabor Kelly wrote: > Laurence Sanford wrote: > > Joseph Koenig (jWeb) wrote: > > > > > This is possible, however you are always taking a chance when you > > installworld without going to single user mode first. That said, I make > > a habit out of pushing my luck with systems I have in front of me by > > going so far as to make installworld while using an xterm in X-windows. > > I routinely use 'portupgrade -rRN' in xterm, in X-Windows to install new > ports on my box. The second to last time I did this, one of the ports > what was upgraded was xterm. And it worked! Can anybody explain to my > why nothing bad happened? Am I running a risk when I do this? This seems pretty safe to me. When xterm gets invoked, the whole of the code gets loaded into memory for execution, and there is no reason why it would look at the disk copy again. If you upgrade the xterm binary, nothing will happen to xterms that are already running. If you create new ones, you will get the new version. I am more surprised that there are still any udpdates being made to xterm - it must have been essentially stable for years now. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remote upgrade possible?
Laurence Sanford wrote: Joseph Koenig (jWeb) wrote: This is possible, however you are always taking a chance when you installworld without going to single user mode first. That said, I make a habit out of pushing my luck with systems I have in front of me by going so far as to make installworld while using an xterm in X-windows. I routinely use 'portupgrade -rRN' in xterm, in X-Windows to install new ports on my box. The second to last time I did this, one of the ports what was upgraded was xterm. And it worked! Can anybody explain to my why nothing bad happened? Am I running a risk when I do this? -- Tabor Kelly [EMAIL PROTECTED] http://tabor.taborandtashell.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Remote upgrade possible?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Joseph Koenig (jWeb) > Sent: Friday, January 07, 2005 3:13 > To: FreeBSD Mailing List > Subject: Remote upgrade possible? > > I have a freebsd 4.9 system that I'd like to get upgraded to 4.10 and then > soon to 4.11. However, the server is not physically in front of me, nor do > I > have physical access to it. Is it possible still to upgrade it, or do I > need > to physically get in front of the machine somehow? Thanks, > > Joe Koenig > Production Manager > jWeb New Media Design > [EMAIL PROTECTED] > http://www.jwebmedia.com/ > 636.928.3162 > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions- > [EMAIL PROTECTED]" \ You can very well upgrade it although upgrading a server remotely over ssh or putty always has that extra bit of risk associated with it. I would not recommend it unless you are old hands at the business. Regards S. Indian Institute of Information Technology Subhro Sankha Kar Block AQ-13/1, Sector V Salt Lake City PIN 700091 India smime.p7s Description: S/MIME cryptographic signature
Re: Remote upgrade possible?
Joseph Koenig (jWeb) wrote: I have a freebsd 4.9 system that I'd like to get upgraded to 4.10 and then soon to 4.11. However, the server is not physically in front of me, nor do I have physical access to it. Is it possible still to upgrade it, or do I need to physically get in front of the machine somehow? Thanks, This is possible, however you are always taking a chance when you installworld without going to single user mode first. That said, I make a habit out of pushing my luck with systems I have in front of me by going so far as to make installworld while using an xterm in X-windows. That said, if you ssh in, and shut down as many things as you can (web servers, mail processes, etc) you should be fine doing this from a distance. The downside is, in the rare event that it does bomb, you're stuck until you can actually get to the box, or unless someone reasonably competent can get to it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Remote upgrade possible?
I have a freebsd 4.9 system that I'd like to get upgraded to 4.10 and then soon to 4.11. However, the server is not physically in front of me, nor do I have physical access to it. Is it possible still to upgrade it, or do I need to physically get in front of the machine somehow? Thanks, Joe Koenig Production Manager jWeb New Media Design [EMAIL PROTECTED] http://www.jwebmedia.com/ 636.928.3162 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
