Bug 1259923
| Summary: | if a policy zone updated during regular operation, then RPZ summary data to fall out of sync | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Sameer Jadhav <sajadhav> | ||||
| Component: | bind | Assignee: | Petr Menšík <pemensik> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Petr Sklenar <psklenar> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.8 | CC: | akarande, pemensik, psklenar, rupatel | ||||
| Target Milestone: | rc | Keywords: | OtherQA, Patch | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | bind-9.8.2-0.55.rc1.el6 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-03-21 10:06:13 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1254457, 1269194, 1359261 | ||||||
| Attachments: |
|
||||||
|
Comment 2
Tomáš Hozza
2015-10-05 12:15:28 UTC
Hi. Based on the information provided in ticket I tried this: 1. generated sample RPZ zone with 3 millions of records using simple script: https://gitlab.com/thozza/random-scripts/blob/master/gen_rpz_zone.py scenario 1: - configured server (A) as master with one RPZ zones each 3m records. - configured sserver (B) with RPZ zone which was slave and transfered from the server (A). - I was querying server (B) with random queries while: - I removed all entries but SOA from the RPZ zone file on server (A) - The server (B) transfered the zone using AXFR - I changed the RPZ zone on server (A) back to 3m records. - The server (B) transfered the zone using AXFR The querying server (B) never locked up and the query resolution never took more than 1 second scenario 2: Same as scenario 1 but with two RPZ zones. I can try to blindly map the changes from upstream to the RHEL-6 code, but having the reproducer is needed to verify that the issue is fixed. Thanks. I went through the patch you requested as the one that should fix the issue.
First part of the patch (patching rbtdb.c) is applicable to the RHEL-6 version of BIND. Based on my understanding this is preventing the possible inconsistencies when zone is updated and addition/deletion of a node fails.
However the second part of the patch (patching rpz.{c,h}) is changing code that is not even present in el6 version of BIND, therefore it can not affect the behavior.
Without a reproducer I can not proceed with the work on possible fix.
Please provide step-by-step reproducer and also backtrace from all threads when bind is in "locked" state (attach to bind while running using 'gdb -p <pid>' and then run 'thread apply all bt'. Don't forget to install the debuginfo packages before doing this, otherwise the backtrace will be worthless.).
Setting Devel Cond NAK 'Reproducer' and 'Patch' for now.
Created attachment 1132733 [details]
baskported relevant part of the upstream fix
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0651.html |