From owner-freebsd-stable@FreeBSD.ORG Tue Apr 19 20:12:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1190516A4CE for ; Tue, 19 Apr 2005 20:12:29 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B3243D3F for ; Tue, 19 Apr 2005 20:12:28 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j3JKCR6v082676 for ; Tue, 19 Apr 2005 15:12:27 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Tue Apr 19 15:12:27 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j3JKCR0b082674 for freebsd-stable@freebsd.org; Tue, 19 Apr 2005 15:12:27 -0500 (CDT) (envelope-from karl) Message-ID: <20050419151227.A82523@denninger.net> Date: Tue, 19 Apr 2005 15:12:27 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org References: <426447F8.5090209@charter.net> <200504191317.j3JDH76H001458@drjekyll.mkbuelow.net> <20050419120053.6ad17df1.wmoran@potentialtech.com> <42655B8E.5020603@mac.com> <42655DD9.7020300@t-hosting.hu> <20050419200510.GA38661@uws1.starlofashions.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20050419200510.GA38661@uws1.starlofashions.com>; from Scott Robbins on Tue, Apr 19, 2005 at 04:05:10PM -0400 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Newbie Question About System Update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 20:12:29 -0000 On Tue, Apr 19, 2005 at 04:05:10PM -0400, Scott Robbins wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Apr 19, 2005 at 09:36:57PM +0200, K?vesd?n G?bor wrote: > > > > >This is generally not the case. Unix lets you continue to access a > > >file after it has been deleted, so long as the process hangs on to a > > >file descriptor. This lets you replace programs in use, without > > >running into the same problems that platforms like Windows have. > > > > Though this is true, I discourage You to upgrade a running system. I > > tried to upgarde 5.3-RELEASE to 5-STABLE without booting to single user > > mode. I simply sent a TERM signal to most of the processes, and tried to > > make installworld. There was some error messages, the system crashed and > > didn't boot anymore... > > There are a couple of servers that I have to upgrade remotely when > necessary. They are active during the working day and almost unused at > night--I just make sure the users know to not leave any files (two are > samba servers as well as doing other things) open if I'm planning an > upgrade--I'm fortunate that my users work with me, and there are only > two who have to be reminded, and neither gives me an argument about it. > > I'm never happy about doing it that way, but what I do is after the > reboot, shut down the various daemons and do the install world and > mergemaster. (This is only after testing the builds on a sacrificial > workstation). > > (And of course the obvious--DO NOT shut down the sshd daemon.) :) > > Ok, everyone who has NEVER ever made that mistake (or locked themself > out with a firewall rule, accidentally putting it into effect before > testing) raise their hand. :) > > > - -- > > Scott > > GPG KeyID EB3467D6 > ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) > gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 When I ran my ISP I updated FreeBSD "hot" all the time. I would build and verify on a "sandbox", and had a piece of custom software (two pieces, actually, a "sender" and "receiver") that would do the moral equivalent of an "rcp" but with moving and then unlinking each executable as it ran (looked at the "x" flag to see if something was executable), adjusting permissions after each file was moved. It was smart enough not to tamper with itself, of course :-> Then the cluster control daemon was told to reboot and off she went. Never got burned doing this; I used to update a cluster consisting of a LOT of machines - we had a window scheduled for it, so customers were warned, but in general due to the way the clustering software worked you'd be lucky if you even noticed unless you were logged into a shell account (at which point you'd lose the telnet session and have to sign back in) The "rolling update" was completely transparent to our web hosting customers (their processes would be assigned to a different machine before each was copied to the new code) It worked fabulously. I've still got the code around somewhere, and I can't imagine why it wouldn't work on the 5.x branch - there's nothing magical that's changed enough to cause trouble with it that I can see. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind