Newbie Question About System Update

Karl Denninger karl at
Tue Apr 19 13:12:29 PDT 2005

On Tue, Apr 19, 2005 at 04:05:10PM -0400, Scott Robbins wrote:
> 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 --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 at Internet Consultant & Kids Rights Activist	My home on the net - links to everything I do!		Your UNCENSORED place to talk about DIVING!		SPAM FREE mailboxes - FREE FOR A LIMITED TIME!	Musings Of A Sentient Mind

More information about the freebsd-stable mailing list