system state after freebsd-update and before portugprade -af

[Matthew Seaman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/06/2010 14:34:43, n dhert wrote:
> When doing a major version upgrade of FreeBSD, the last (mandatory) step is
> to rebuild and reinstall all third party software (ports)
> (# portupgrade -af )
> 
> I have a system with 750+ ports, I guess the portupgrade -af will take
> something like 30 hours to compile
> (on a test system with 425 ports portugprade -af took 15 hours).
> 
> What happens in the periode that not every port is yet rebuilt and
> reinstalled?
> Will applications (webserver, print server, X server, and the many other
> apps) not be working,
> until these ports (and the ports they depend on) will be successfully
> recompiled ?

It's a mixed bag, really.  Unless you can build all your required ports
off-line, and then do all the upgrading via packages you're going to
have hours of downtime and various other possible effects on service.

You can sort-of do this upgrade in-place on a "live" system, but you'ld
have to do it at a weekend or overnight or whenever your site gets
minimum traffic.  You've also got to watch the upgrade process
carefully, and restart daemons as required.  Eg. something like mysql
will be stopped on deinstall, but you'll have to restart it as soon as
the updated version is installed.  Check pkgtools.conf -- there's foo
you can put in the AFTERINSTALL hash to try and automate that:

  AFTERINSTALL = {
    '*' => proc { |origin|
       cmd_start_rc(origin)
    },
  }

On the other hand, for something like Apache+mod_php, you don't want to
bounce apache until all of the php5 and pecl modules have been rebuilt.
 Your php applications probably won't work during the time everything is
being rebuilt.

Shared libraries will generally get rebuilt fairly early in the process.
 In general this will not cause any running application that links
against the old version of the shlib to stop running.  It may well
prevent starting a new instance of a process, even though there are
backup copies of the old shlib saved in /usr/local/compat/pkg.  That's
potentially a big Ooops.

In summary: probably best to arrange enough downtime to do the upgrade
and just turn everything off while you are doing it.  If you really need
minimum downtime, think about one of the following:

    * Create a jail on your server, build all required ports as
      packages and then do your upgrade by package juggling only

    * Build a whole new system in a jail in its own partition, then
      reboot using that partition as the root.  Works particularly
      well if your system is using ZFS.

    * Use a spare machine to build an upgraded system, switch it
      in place of the live server, then upgrade the live box at leisure
      and switch back. (Works well in combination with the packages
      only method above.)

There are other tricks, like splitting a RAID1 mirror, upgrading one of
the disks only, then only once the upgrade has been tested and approved
do you put the mirror back together and resynch.  In this case, if it
all goes horribly wrong, you can just reboot from the other half of the
mirror back into the original system and then resynch in the other
direction to get back to square one.  You can have the server back live
running on one disk while you rebuild the other or while the resynch is
happening if you need to.

	Cheers,

	Matthew

- -- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwXjkUACgkQ8Mjk52CukIwN1gCglHMeFnwryuUM9K8xaEnGB9SZ
kJwAnRLTWPDwyrc4p85W1F/ROXH9Qqky
=a8iR
-----END PGP SIGNATURE-----