ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-10-05T12:25:35Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1869tsig-confgen dumps core2021-10-05T12:25:35ZMichal Nowaktsig-confgen dumps core`tsig-confgen` from BIND `master` (6f576b2c184c3ffdae7ecbea5f7cb40e6d302b0d) dumps core on CentOS 8:
```
$ gdb tsig-confgen
...
(gdb) continue
Continuing.
warning: Loadable section ".note.gnu.property" outside of ELF segments
ddns-confg...`tsig-confgen` from BIND `master` (6f576b2c184c3ffdae7ecbea5f7cb40e6d302b0d) dumps core on CentOS 8:
```
$ gdb tsig-confgen
...
(gdb) continue
Continuing.
warning: Loadable section ".note.gnu.property" outside of ELF segments
ddns-confgen.c:133: INSIST(0) failed, back trace
/lib64/libisc.so.1701(+0x2e5c3) [0x7ffff7b8c5c3]
/lib64/libisc.so.1701(isc_assertion_failed+0xa) [0x7ffff7b8c537]
/usr/sbin/tsig-confgen() [0x4014ed]
/lib64/libc.so.6(__libc_start_main+0xf3) [0x7ffff558c873]
/usr/sbin/tsig-confgen() [0x40125e]
Program received signal SIGABRT, Aborted.
0x00007ffff55a08df in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libgcc-8.3.1-4.5.el8.x86_64
(gdb) thread apply all bt full
Thread 1 (Thread 0x7ffff7fe10c0 (LWP 4396)):
#0 0x00007ffff55a08df in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007ffff558acf5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007ffff7b8c53c in isc_assertion_failed (file=file@entry=0x402794 "ddns-confgen.c", line=line@entry=133, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x402792 "0") at assertions.c:47
No locals.
#3 0x00000000004014ed in main (argc=1, argv=0x7fffffffd998) at ddns-confgen.c:133
result = <optimized out>
show_final_mem = false
quiet = false
key_txtbuffer = {magic = 0, base = 0x0, length = 255, used = 0, current = 4096, active = 0, link = {prev = 0x1020, next = 0x0}, mctx = 0x0, autore = 221}
key_txtsecret = "\000\000\000\000\000\000\000\000\067\351^\365\377\177\000\000 \020\000\000\000\000\000\000\020\000\000\000\000\000\000\000\243\220x\364\377\177\000\000\230\331\377\377\377\177\000\000\250\331\377\377\377\177\000\000\256$_\365\377\177\000\000\243\220x\364\377\177\000\000\243\220x\364\377\177\000\000\000\000\000\000\000\000\000\000n\fw\364\377\177\000\000\000\020\000\000\000\000\000\000\000\020", '\000' <repeats 63 times>, "\020\000\000\000\000\000\000\377", '\000' <repeats 31 times>...
mctx = 0x0
keyname = 0x0
zone = 0x0
self_domain = 0x0
keybuf = 0x0
alg = 163 '\243'
algname = <optimized out>
keysize = 256
len = 0
ch = <optimized out>
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1868Clean up code determining advertised EDNS UDP buffer size2020-05-25T13:52:57ZMichał KępieńClean up code determining advertised EDNS UDP buffer sizeWhile looking at some packet captures, I noticed what looked like
oddities in how `named` sets the advertised UDP buffer size in the EDNS
queries it sends to servers which have intermittent network issues. In
the end, I did not find any...While looking at some packet captures, I noticed what looked like
oddities in how `named` sets the advertised UDP buffer size in the EDNS
queries it sends to servers which have intermittent network issues. In
the end, I did not find any obvious bugs, but I believe the
documentation does not match the code in a few places and it also
occurred to me that the [code][1] determining the advertised UDP buffer
size in outgoing queries is cryptic enough for me to be unable to
predict what the outcome will be in pretty much *any* scenario.
I think it would be nice to rip out the redundant bits, add comments,
and make sure the documentation matches the code (either by updating the
former or fixing the latter). Such changes would likely not need to be
backported to 9.16 (and beyond).
This is not particularly urgent, though it is slightly related to [DNS
Flag Day 2020][2].
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/6f576b2c184c3ffdae7ecbea5f7cb40e6d302b0d/lib/dns/resolver.c#L2648-2687
[2]: https://dnsflagday.net/2020/June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/1245convert parsing of global entries to flat style2020-06-18T20:13:11ZFrancis Dupontconvert parsing of global entries to flat styleIn json_config_parser.cc the loop parsing global entries incorrectly assumes entries are handled in the code order when they are in the alphabetic entry name order. The code must be converted into the flat style to enforce this property.In json_config_parser.cc the loop parsing global entries incorrectly assumes entries are handled in the code order when they are in the alphabetic entry name order. The code must be converted into the flat style to enforce this property.kea1.7.9Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1867Fix the system tests on Windows2020-07-14T12:50:33ZOndřej SurýFix the system tests on WindowsNow, that the BIND 9 builds on Windows again, we need to fix the system tests:
```
$ & sh.exe runall.sh $TEST_PARALLEL_JOBS
/bin/bash: ./run.sh: No such file or directory
[...]
/bin/bash: ./run.sh: No such file or directory
I:System test...Now, that the BIND 9 builds on Windows again, we need to fix the system tests:
```
$ & sh.exe runall.sh $TEST_PARALLEL_JOBS
/bin/bash: ./run.sh: No such file or directory
[...]
/bin/bash: ./run.sh: No such file or directory
I:System test result summary:
I:Found 0 test results, but 95 tests were run
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/stork/-/issues/277HA status UI widget does not show properly some state2020-10-30T17:17:49ZMichal NowikowskiHA status UI widget does not show properly some state![image](/uploads/c73700a75fdacff99be4baa2e447066b/image.png)
In Local Server `state` is empty, it has only red cross.
![image](/uploads/1e960ff9d17044895bfb951c20af70c8/image.png)
Here in the same server this state is reported as `not ...![image](/uploads/c73700a75fdacff99be4baa2e447066b/image.png)
In Local Server `state` is empty, it has only red cross.
![image](/uploads/1e960ff9d17044895bfb951c20af70c8/image.png)
Here in the same server this state is reported as `not configured` but it should be something else.0.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1866dumpdb take 12+ seconds to complete.2021-10-05T12:18:21ZMark Andrewsdumpdb take 12+ seconds to complete.Job [#896675](https://gitlab.isc.org/isc-projects/bind9/-/jobs/896675) failed for 4df013f0ea61d927abf4f67d5c6ab04478b53d28:
cacheclean system test failed because dumpdb took excessive time to complete.
```
I:cacheclean:check the number...Job [#896675](https://gitlab.isc.org/isc-projects/bind9/-/jobs/896675) failed for 4df013f0ea61d927abf4f67d5c6ab04478b53d28:
cacheclean system test failed because dumpdb took excessive time to complete.
```
I:cacheclean:check the number of cached records remaining (13)
I:cacheclean:timed out waiting for 'rndc dumpdb' to finish
Can't open ns2/named_dump.db.test13: No such file or directory.
I:cacheclean:found 0 records expected 1
I:cacheclean:failed
```
```
21-May-2020 04:21:38.807 received control channel command 'dumpdb -cache _default'
21-May-2020 04:21:38.807 dumpdb started: -cache
21-May-2020 04:21:38.807 delete_node(): 0x7febb871ad68 second1.top1.flushtest.example (bucket 94)
21-May-2020 04:21:38.807 delete_node(): 0x7febb871fc20 top2.flushtest.example (bucket 0)
21-May-2020 04:21:38.807 delete_node(): 0x7feb4fe51bd0 second1.top3.flushtest.example (bucket 36)
21-May-2020 04:21:38.807 delete_node(): 0x7febb871aa38 second2.top3.flushtest.example (bucket 0)
21-May-2020 04:21:48.887 socket 0x7febb8801600: internal_accept called, locked socket
21-May-2020 04:21:48.887 socket 0x7febb8801600 10.53.0.1#38867: accepted connection, new socket 0x7febb83e8310
21-May-2020 04:21:50.555 expiring v4 for name 0x7febb858f270
21-May-2020 04:21:50.675 killing name 0x7febb858f270
21-May-2020 04:21:50.675 ENTER clean_finds_at_name, name 0x7febb858f270, evtype 0004000d, addrs 00000003
21-May-2020 04:21:50.675 EXIT clean_finds_at_name, name 0x7febb858f270
21-May-2020 04:21:50.687 dumpdb complete
```https://gitlab.isc.org/isc-projects/kea/-/issues/1244KB on How to upgrade/update Kea2020-06-24T21:55:20ZVicky Riskvicky@isc.orgKB on How to upgrade/update KeaWe would like a generic 'How to update your Kea server' with special instructions if the update includes a db schema change and special instructions for an HA pair. If there are any other special cases, include those.
Then in the releas...We would like a generic 'How to update your Kea server' with special instructions if the update includes a db schema change and special instructions for an HA pair. If there are any other special cases, include those.
Then in the release notes, we can tell them if they need to use one of these special cases (based on what the changes are in the release.)kea1.7.9Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1864Commit 54fe75b9b76eba92efd0fc1cded4a0ac0adc0ba9 introduced a regression in 9.112021-10-05T12:17:40ZBrian ConryCommit 54fe75b9b76eba92efd0fc1cded4a0ac0adc0ba9 introduced a regression in 9.11This commit causes a problem in 9.11 when using `query-source` with `port 53`.
After a reconfig or reload the server will stop receiving data.
I've confirmed that 9.14 and later versions are not affected.
I've also confirmed that both ...This commit causes a problem in 9.11 when using `query-source` with `port 53`.
After a reconfig or reload the server will stop receiving data.
I've confirmed that 9.14 and later versions are not affected.
I've also confirmed that both 9.11 and 9.11-S are affected.
This was discovered from a customer ticket, though the customer has since removed the query source port configuration.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1863dnssec-verify specify a current time2024-02-14T14:44:27ZPeter Daviesdnssec-verify specify a current time### Description
dnssec-verify specify a current time:
If we generate a signed zone via dnssec-signzone with an inception time in the future, then we have a way to fully verify it (including signature validity time checks) with dnssec-ve...### Description
dnssec-verify specify a current time:
If we generate a signed zone via dnssec-signzone with an inception time in the future, then we have a way to fully verify it (including signature validity time checks) with dnssec-verify before hand.
### Request
A command line parameter that allowed you to specify a current time to be used by dnssec-verify.
### Links / references
[GL #743 ](https://gitlab.isc.org/isc-projects/bind9/-/issues/743)
[RT #16466](https://support.isc.org/Ticket/Display.html?id=16466)Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/276Accept new format of the status-get command2020-05-29T05:39:05ZMarcin SiodelskiAccept new format of the status-get commandIn Kea 1.7.8 we are going to have new format of the `status-get` command. See https://gitlab.isc.org/isc-projects/kea/-/issues/1087. Stork should be prepared to accept this new format. In addition to moving the existing parameters there ...In Kea 1.7.8 we are going to have new format of the `status-get` command. See https://gitlab.isc.org/isc-projects/kea/-/issues/1087. Stork should be prepared to accept this new format. In addition to moving the existing parameters there are also new parameters returned which describe the state of the failover when the communication between the servers is interrupted.0.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1862query.c:8628: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x...2020-09-09T14:48:49ZWitold Krecickiquery.c:8628: INSIST(qctx->is_zone || (((qctx->client)->query.attributes & 0x20000) != 0)) failed, back traceResolver crashes when queried when starting up if both qname minimization and root mirroring is configured.
When we're coming back from recursion we don't accept DNS_R_NXDOMAIN as an answer (hence the INSIST).
Here, the DNS_R_NXDOMAIN ...Resolver crashes when queried when starting up if both qname minimization and root mirroring is configured.
When we're coming back from recursion we don't accept DNS_R_NXDOMAIN as an answer (hence the INSIST).
Here, the DNS_R_NXDOMAIN is returned by:
resume_qmin:4403 -> dns_view_findzonecut:1355 -> dns_db_find()July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1861named_checknames_get missing DBC2020-05-25T01:56:50ZMark Andrewsnamed_checknames_get missing DBCJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1860delv crashes processing deprecated "trusted-keys" clause in anchor file2020-06-08T10:16:16ZStephen Morrisdelv crashes processing deprecated "trusted-keys" clause in anchor file<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
The "trusted-keys" clause in a delv anchor file is deprecated, being replaced by "trust-anchors". However, "trusted-keys" should still be accepted, but `delv` crashes on encountering it. (In the examples below, the key is a locally-generated key.)
### DELV version used
commit a53bc0b28b0b1d1b5a715e4a1b88b83e7fbe82fe
### Steps to reproduce
```
612% delv -v
delv 9.17.1-dev
613%
613%
613% cat delv-1.keys
trust-anchors {
. static-key 257 3 8 "AwEAAcOhhbamHAu0j6x+VFH/KXfKjoqtfxE6B5SYyLq4770t5FP7EOjA
qKRFwcVswbgmn/ttZ4QBVS+3+h9VueDulG/dP1NfMj1NbrlL/PoOXTt0
x1SMR3YX6NOZyZooJzqg/ffx13NyX8Lfj9Ni4dh+naR7lNXpL1KtMzku
NlDgcHipnmBRlXT3tbff/VUr1MXDPTwsNZAl295VZFev3ztXI06I0bkp
BNOErVMJLLGfqBA0q/WhibOOWelz4xG92n+hDeDyHkR3qAOkKegZePQ9
h4GmJS+f+dSMD/1r7XvwGTznL7UjYXDqheBdZGboBEXjOAFm/U69OhG6
ky/e2H1xPXs=";
};
614% delv -a delv-1.keys
;; validating ./NS: got insecure response; parent indicates it should be secure
;; insecurity proof failed resolving './NS/IN': 194.168.4.100#53
;; validating ./NS: got insecure response; parent indicates it should be secure
;; insecurity proof failed resolving './NS/IN': 194.168.8.100#53
;; resolution failed: insecurity proof failed
615%
615%
615% cat delv-2.keys
trusted-keys {
. 257 3 8 "AwEAAcOhhbamHAu0j6x+VFH/KXfKjoqtfxE6B5SYyLq4770t5FP7EOjA
qKRFwcVswbgmn/ttZ4QBVS+3+h9VueDulG/dP1NfMj1NbrlL/PoOXTt0
x1SMR3YX6NOZyZooJzqg/ffx13NyX8Lfj9Ni4dh+naR7lNXpL1KtMzku
NlDgcHipnmBRlXT3tbff/VUr1MXDPTwsNZAl295VZFev3ztXI06I0bkp
BNOErVMJLLGfqBA0q/WhibOOWelz4xG92n+hDeDyHkR3qAOkKegZePQ9
h4GmJS+f+dSMD/1r7XvwGTznL7UjYXDqheBdZGboBEXjOAFm/U69OhG6
ky/e2H1xPXs=";
};
616% delv -a delv-2.keys
;; delv-2.keys:1: option 'trusted-keys' is deprecated
parser.c:1711: REQUIRE(obj != ((void*)0) && obj->type->rep == &cfg_rep_string) failed, back trace
0 libisc.1701.dylib 0x00000001042c618a default_callback + 74
1 libisc.1701.dylib 0x00000001042c611a isc_assertion_failed + 10
2 libisccfg.1700.dylib 0x0000000104545c58 cfg_obj_asstring + 56
3 delv 0x00000001042a4fd9 load_keys + 457
4 delv 0x00000001042a3dca main + 8938
5 libdyld.dylib 0x00007fff71d2b3d5 start + 1
Abort trap: 6
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/kea/-/issues/1242Config backend: low performance on loading large number of subnets2020-05-29T21:28:09ZMarcin SiodelskiConfig backend: low performance on loading large number of subnetsWe have been chasing the problem with long time taking to fetch large number of subnets from the MySQL config backend. This was narrowed down as a problem with indexing on the dhcp4_options table referencing subnets. The indexing must be...We have been chasing the problem with long time taking to fetch large number of subnets from the MySQL config backend. This was narrowed down as a problem with indexing on the dhcp4_options table referencing subnets. The indexing must be corrected and we need to investigate if there are other similar problems in the schema.kea1.7.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1859Possible deadlock in unix/socket.c2020-06-18T08:26:36ZWitold KrecickiPossible deadlock in unix/socket.cIn process_fd we lock sock->lock, and then in internal_accept called from it we lock manager->lock while holding sock->lock
In isc_socketmgr_render{xml,json} we lock manager->lock and then for each sock we lock sock->lock.
That can cause...In process_fd we lock sock->lock, and then in internal_accept called from it we lock manager->lock while holding sock->lock
In isc_socketmgr_render{xml,json} we lock manager->lock and then for each sock we lock sock->lock.
That can cause a deadlock.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1858Silence TSAN in bin/nsupdate/nsupdate.c2020-05-28T01:14:09ZMark AndrewsSilence TSAN in bin/nsupdate/nsupdate.c```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 dns_rdataset_isassociated lib/dns/rdataset.c:143
#1 msgresetnames lib/dns/message.c:479
#2 msgreset lib/dns/message.c:564
#3 d...```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by main thread:
#0 dns_rdataset_isassociated lib/dns/rdataset.c:143
#1 msgresetnames lib/dns/message.c:479
#2 msgreset lib/dns/message.c:564
#3 dns_message_destroy lib/dns/message.c:837
#4 cleanup nsupdate.c:3245
#5 main nsupdate.c:3351
Previous write of size 8 at 0x000000000001 by thread T1:
#0 dns_rdataset_init lib/dns/rdataset.c:62
#1 getquestions lib/dns/message.c:1147
#2 dns_message_parse lib/dns/message.c:1740
#3 dns_request_getresponse lib/dns/request.c:1298
#4 update_completed nsupdate.c:2383
#5 dispatch lib/isc/task.c:1157
#6 run lib/isc/task.c:1331
#7 <null> <null>
Location is heap block of size 113 at 0x000000000012 allocated by thread T1:
#0 malloc <null>
#1 internal_memalloc lib/isc/mem.c:887
#2 mem_get lib/isc/mem.c:792
#3 isc___mempool_get lib/isc/mem.c:2083
#4 isc__mempool_get lib/isc/mem.c:3088
#5 dns_message_gettemprdataset lib/dns/message.c:2597
#6 dns_message_setquerytsig lib/dns/message.c:2897
#7 dns_request_getresponse lib/dns/request.c:1292
#8 update_completed nsupdate.c:2383
#9 dispatch lib/isc/task.c:1157
#10 run lib/isc/task.c:1331
#11 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:60
#2 isc__taskmgr_create lib/isc/task.c:1468
#3 isc_taskmgr_create lib/isc/task.c:2109
#4 setup_system nsupdate.c:994
#5 main nsupdate.c:3344
SUMMARY: ThreadSanitizer: data race lib/dns/rdataset.c:143 in dns_rdataset_isassociated
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1857assertion failure in 9.16.2: name.c:1738: INSIST(nlabels == name->labels)2020-06-23T05:01:40ZEvan Huntassertion failure in 9.16.2: name.c:1738: INSIST(nlabels == name->labels)Reported by Kevan Benson at Sonic, this has happened on two separate servers, Centos 7.8.2003 and FreeBSD 11.3.
Backtrace is [here](/uploads/4221622ae7fdfe5d4d2f0906dfcb35a1/named-backtrace.log).Reported by Kevan Benson at Sonic, this has happened on two separate servers, Centos 7.8.2003 and FreeBSD 11.3.
Backtrace is [here](/uploads/4221622ae7fdfe5d4d2f0906dfcb35a1/named-backtrace.log).June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1856Race in 'clear signing records' in dnssec system test.2020-05-19T03:52:24ZMark AndrewsRace in 'clear signing records' in dnssec system test.Job [#892140](https://gitlab.isc.org/isc-projects/bind9/-/jobs/892140) failed for 3353bbbe4ae1cb238e8b80a0877969b4a0357f45:
Updates to the zone are task locked and rndc command to clear the key returns as it is being processed. The
subs...Job [#892140](https://gitlab.isc.org/isc-projects/bind9/-/jobs/892140) failed for 3353bbbe4ae1cb238e8b80a0877969b4a0357f45:
Updates to the zone are task locked and rndc command to clear the key returns as it is being processed. The
subsequent rndc command to check can happen before the zone has updated.
```
I:dnssec:clear signing records (170)
I:dnssec:ns3 Done signing with key 14616/NSEC3RSASHA1
I:dnssec:failed
```
```
echo_i "clear signing records ($n)"
{ rndccmd 10.53.0.3 signing -clear all update-nsec3.example > /dev/null; } 2>&1 || ret=1
sleep 1
{ rndccmd 10.53.0.3 signing -list update-nsec3.example > signing.out; } 2>&1
grep -q "No signing records found" signing.out || {
ret=1
sed 's/^/ns3 /' signing.out | cat_i
}
n=$((n+1))
test "$ret" -eq 0 || echo_i "failed"
status=$((status+ret))
```
```
18-May-2020 22:26:03.628 received control channel command 'signing -clear all update-nsec3.example'
18-May-2020 22:26:03.628 keydone: zone update-nsec3.example/IN: enter
...
18-May-2020 22:26:03.640 del update-nsec3.example. 0 IN TYPE65534 \# 5 0739180001
...
18-May-2020 22:26:04.708 received control channel command 'signing -list update-nsec3.example'
...
18-May-2020 22:26:05.032 zone_needdump: zone update-nsec3.example/IN: enter
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1855"check max-journal-size limits" failed as not enough time allowed2020-05-18T22:19:28ZMark Andrews"check max-journal-size limits" failed as not enough time allowedJob [#890395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/890395) failed for d9f357d082da2f8ad68818771ccee96cbe72c0ee:
Test looped for 6 seconds when it took ~13 second.
```
n=`expr $n + 1`
echo_i "check max-journal-size limits ($...Job [#890395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/890395) failed for d9f357d082da2f8ad68818771ccee96cbe72c0ee:
Test looped for 6 seconds when it took ~13 second.
```
n=`expr $n + 1`
echo_i "check max-journal-size limits ($n)"
ret=0
rm -f nsupdate.out1-$n
# add one record
$NSUPDATE << EOF >> nsupdate.out1-$n 2>&1
server 10.53.0.1 ${PORT}
zone maxjournal.test
update add z.maxjournal.test 300 IN A 10.20.30.40
send
EOF
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do
# repeatedly add and remove the same set of records to fill up
# the journal file without changing the zone content
$NSUPDATE << EOF >> nsupdate.out1-$n 2>&1
server 10.53.0.1 ${PORT}
zone maxjournal.test
update add a.maxjournal.test 300 IN A 1.2.3.4
update add b.maxjournal.test 300 IN A 1.2.3.4
update add c.maxjournal.test 300 IN A 1.2.3.4
update add d.maxjournal.test 300 IN A 1.2.3.4
send
update del a.maxjournal.test
update del b.maxjournal.test
update del c.maxjournal.test
update del d.maxjournal.test
send
EOF
done
# check that the journal is big enough to require truncation.
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -gt 6000 ] || ret=1
sleep 1
$RNDCCMD 10.53.0.1 sync maxjournal.test
for i in 1 2 3 4 5 6
do
sleep 1
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -lt 5000 ] && break
done
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -lt 5000 ] || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
```
```
18-May-2020 06:17:34.729 received control channel command 'sync maxjournal.test'
18-May-2020 06:17:34.733 zone_dump: zone maxjournal.test/IN: enter
18-May-2020 06:17:34.737 zone_gotwritehandle: zone maxjournal.test/IN: enter
18-May-2020 06:17:34.737 sync: dumping zone 'maxjournal.test/IN': success
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: socket_recv: event 0x7fb57ffde180 -> task 0x7fb58fc8b020
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -3 for socket 155
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -2 for socket -1
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: internal_recv: event 0x7fb57ffde180 -> task 0x7fb58fc8b020
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: destroying
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -5 for socket 155
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -2 for socket -1
18-May-2020 06:17:36.025 zone_timer: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_maintenance: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_dump: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_settimer: managed-keys-zone: enter
18-May-2020 06:17:45.393 dump_done: zone maxjournal.test/IN: enter
18-May-2020 06:17:45.393 zone_journal_compact: zone maxjournal.test/IN: target journal size 318
18-May-2020 06:17:45.393 journal file maxjournal.db.jnw does not exist, creating it
18-May-2020 06:17:47.353 zone maxjournal.test/IN: dns_journal_compact: success
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1854Extend loop limit by 1.2020-05-21T04:11:46ZMark AndrewsExtend loop limit by 1.Job [#889797](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889797) failed for 46c4e5d96f4b024117b4e462d3929bb68cb63136:
Extend the loop count by 1 to account for non-exact timing in `usleep(100000)`.
```
[==========] Running 6 test...Job [#889797](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889797) failed for 46c4e5d96f4b024117b4e462d3929bb68cb63136:
Extend the loop count by 1 to account for non-exact timing in `usleep(100000)`.
```
[==========] Running 6 test(s).
[ RUN ] getoriginnode_test
[ OK ] getoriginnode_test
[ RUN ] getsetservestalettl_test
[ OK ] getsetservestalettl_test
[ RUN ] dns_dbfind_staleok_test
21 is not within the range 0-20
db_test.c:214: error: Failure!
[ FAILED ] dns_dbfind_staleok_test
[ RUN ] class_test
[ OK ] class_test
[ RUN ] dbtype_test
[ OK ] dbtype_test
[ RUN ] version_test
[ OK ] version_test
[==========] 6 test(s) run.
[ PASSED ] 5 test(s).
[ FAILED ] 1 test(s), listed below:
[ FAILED ] dns_dbfind_staleok_test
1 FAILED TEST(S)
FAIL db_test (exit status: 1)
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrews