On Fri, Aug 21, 2009 at 10:35:13PM -0600, LaMont Jones wrote:
> On Sat, Aug 22, 2009 at 10:47:16AM +1000, Craig Sanders wrote:
> > when upgrading bind9, named is stopped until the upgrade is completed.
>
> And there is no real way to make sure it stays working while the
> libraries and such are changed out from under it, based on some of the
> issues we ran into earlier in the bind9 train, which caused me to quit
> trying to keep it running during a dist-upgrade.
what issues?
i've never had a problem with bind restarting after upgrade in all the
i'years ve been running it and upgrading it.
the ONLY time i've ever had serious problems upgrading bind is when it
has had this bug, taking down the entire network for the duration of the
upgrade.
> > this could be a LONG time during an apt-get
> > {dist-,dselect-,}upgrade, especially if there are many packaged
> > being upgraded or if there are any debconf questions waiting to be
> > answered.
>
> And more reason to upgrade daemons in separation from the rest of the
> machine.
which daemons in particular?
on most of the machines i run bind on, daemons are pretty much ALL that
they run.
in effect, you're saying "don't bother with apt-get dist-upgrade, just
upgrade each package individually"
part of the reason for running debian is so you don't have to remember
stupid crap like "upgrade bind before postfix unless you're running
squid, in which case you need to upgrade this first and then that". and
then hope that the sequence hasn't changed since the last time because
some new dependancy has been introduced.
that's what dependancies and pre-depends are for.
> > this has an obvious seriously detrimental and prolonged effect on
> > the entire local network which depends on that nameserver.
>
> > this is a repeat of an earlier bug (#453765), which was reported in
> > Dec 2007 and fixed in June 2008. It has come back.
>
> And if I recall, it was intentionally reintroduced to fix an issue
> with stopping the old daemon after the upgrade failed in a manner that
> made it seem to be a bad thing to do.
huh? AFAICT, it is only the most recent version of bind9 that has
re-introduced the bug (at least, i hadn't noticed it until today). if
you can't recall why such a recent change was made, then perhaps there
wasn't a good reason for it.
> > see also bug #471060 (debhelper, reported Mar 2008, fixed May 2008).
> > a '--restart-after-upgrade' option was added to dh_installinit to
> > provide a fix this behaviour. There was some suggestion that this
> > might become the default behaviour but it looks like that hasn't
> > happened.
>
> I'll have to revisit the whole issue, but the switch to using
> dh_installinit was done separate from
the first time around for this bug bind9 was already using dh_installinit.
> the "don't bother trying to keep it running through the upgrade"
> decision.
that decision equates to "we don't give a damn about our users'
networks".
a working nameserver is a core, essential component of a functioning
network. while named is down, *everything* on the network that uses that
nameserver ceases to function correctly.
minimising downtime for core network services is, and should be, a priority.
craig
--
craig sanders <c...@taz.net.au>
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
