Hi again Seeing as I started all this with my original post. Perhaps I'd better close off by saying a couple of things. 1. It appears that the very process (ensuring no regression errors creep back in) that is stopping this problem being fixed in a reasonable time-scale, is the very same process that failed to stop this particular regression error. Some sort of twisted catch-22 logic there! 2. I put in an easy to monitor workaround, by setting DISABLE_ZONE_CHECKING="yes" in /etc/sysconfig/named. I can always run a manual named-chkconfig if I need to and now I won't get caught out on the next update. Cheers and thanks for all the valuable insights. Bill -----Original message----- > From:Steven Haigh <[log in to unmask]> > Sent: Saturday 19th March 2016 8:43 > To: [log in to unmask] > Subject: Re: named-chroot issue - AGAIN > > On 19/03/2016 1:31 AM, Tom H wrote: > > On Thu, Mar 17, 2016 at 11:17 PM, David Sommerseth > > <[log in to unmask]> wrote: > >> On 17/03/16 13:23, Tom H wrote: > >>> On Thu, Mar 17, 2016 at 12:53 PM, David Sommerseth > >>> <[log in to unmask]> wrote: > >>>> > >>>> Not going to argue that this could have been done better, I agree with you > >>>> here. On the other hand, maybe *that* is one reason it takes time to get this > >>>> issue resolved too? That Red Hat QE is working on improving the situation, > >>>> adding needed regression tests and so on for this use case. I know I'm > >>>> speculating now, but I also know that these guys really do their best to avoid > >>>> painful experiences for users and customers. Unfortunately, they do mistakes > >>>> - as we all do from time to time. > >>> > >>> Given the > >>> https://git.centos.org/blobdiff/rpms!bind.git/d56ed2d3a2736a07a09c268f3b2607cca8f1b6ca/SOURCES!named-chroot.service > >>> commit, there's probably a lot of hype in RH's QA marketing claims. > >>> I'm not implying that there's no QA at all but, in this case, if there > >>> was any, it sucked. > >> > >> The people working on CentOS are not the same people working on RHEL, > >> even if they're working in the same company. And RHEL is still the > >> upstream source of CentOS. > >> > >> So if CentOS decides to fix this on their own, they need to keep track > >> of this until it's fixed in RHEL and then remove their own fix. Of > >> course SL could do that as well, but that can be a maintenance burden. > >> > >> That's the downside of being a downstream distro. > > > > Just because it's on git.centos.org doesn't mean that this is a CentOS > > change. It's an import from RH. CentOS doesn't diverge from RHEL with > > downstream patches. And, AFAIK, SL uses pristine RH sources and not > > those modified by CentOS. > > Correct - that was my point. This is part of a change that RH pushed > internally and to CentOS. The origin is RedHat - and the change shows > the source of the bug - RedHat :) > > -- > Steven Haigh > > Email: [log in to unmask] > Web: https://www.crc.id.au > Phone: (03) 9001 6090 - 0412 935 897 > >