On Sun, Aug 23, 2009 at 06:00:11PM -0600, LaMont Jones wrote: > On Mon, Aug 24, 2009 at 07:47:59AM +1000, Craig Sanders wrote: > > i'm talking about a network being disrupted, not a single host. the > > hosts DON'T have 127.0.0.1 in resolv.conf, they have the namesever. > > I've gone back as far as 9.2.4, and haven't found anywhere that the > bind9 package actually kept itself from stoping bind9 during the > upgrade. I do know that bind 8 had code in the scripts to do that.
i've already mentioned bug #453765. that bug was closed on Fri, 13 Jun 2008 16:54:42 -0600 with the following message signed by you: * Leave named running during update. Closes: #453765 > > > It's not critical severity - normal or wishlist would be more > > > appropriate. > > > > it is critical. it breaks functionality for the entire local > > network. > > Generally what I've seen done is a separate IP for the resolver, and > during a scheduled upgrade, that IP is migrated to another host, > specifically to avoid any disruption. why jump through such bizarrely complicated and dangerous hoops to avoid a non-problem? bind9 has never had a single demonstrated problem with restart-after-upgrade. and what do you do if you're ssh-ed in to that machine on that IP address? you can't change it, otherwise you kill your ssh connection. (BTW, ssh along with pppd are the two classic examples of why it's a really bad idea to stop-before-upgrade and start-after instead of restart-after. for those packages, that not only maximises downtime it can prevent logging in to fix any errors. named can too, if hosts.allow/hosts.deny are configured to reject ssh from unknown hostnames or to only allow connections from your domain). > > it's not a matter of convenience. it's a matter of temporarily > > breaking everything on the network that depends on DNS (which is > > pretty much every network service or connection). > > Everything on the network that depends on this host for DNS. which is, as i said, pretty much every network service or connection. > Migrating the service to another host for the duration of the upgrade, > or doing micro upgrades is certainly an option. an even better option is for the bind9 package to actually make some effort to minimise downtime by restarting after upgrade rather than stopping early and starting late. I'm still waiting to hear of any of the alleged problems caused by restarting after upgrade that have been alluded to and hinted at so mysteriously. so far, not one has even been theorised let alone demonstrated to have happened. and i can not fathom why there's so much resistance to just adding '--restart-after-upgrade' to the call to dh_installinit. it's a very simple fix with no downside. > > the bind9 package has worked reliably for many years with a restart > > after upgrade rather than stop-early, start-late approach. there is no > > reason for the current change in behaviour. it just maximises downtime. > > Versions? i don't know the version numbers, nor do i have an archive of every historical release of the bind9 package to go searching through. i can give you approximate dates instead: it was fine for years before i reported the problem the first time in Dec 2007 (bug #453765), and has been fine since that bug was closed in June 2008 up until the recent change that re-introduced the bug. 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
