Stephen Morris [Fri, 15 Dec 2017 15:56:33 +0000 (15:56 +0000)]
[rt46602] Ensure test output in systests.output is not mixed up
When running all the system tests, output from a test is sent to a
test.output file in the test directory. These are combined in to
systests.output when the run finishes.
Stephen Morris [Thu, 23 Nov 2017 10:02:15 +0000 (10:02 +0000)]
[rt46602] Tidy up run management
Miscellaneous tidying up of run management. The most significant
change is that "runall.sh" now runs _all_ the tests, even the
ones that can run in parallel. runsequential.sh is the script
to run tests that have not been converted to parallel running.
Stephen Morris [Thu, 23 Nov 2017 09:58:57 +0000 (09:58 +0000)]
[rt46602] Assign block of ports for each test
Some tests use more ports than just the query and control ports.
Each test that can run in parallel with other tests is now assigned
a unique block of 10 ports.
Stephen Morris [Fri, 17 Nov 2017 17:29:21 +0000 (17:29 +0000)]
[rt46602] Miscellaneous changes to existing parallelised tests
Currently these tests are allow_query, rpzrecurse and serve-stale
1. Function to copy files and set port numbers renamed from copy_config
to copy_setports, as this is used to change the ports in Perl and Python
test scripts as well.
2. Changes to rpzrecurse/tests.sh to handle two calls to getopts (one to
parse port numbers, the other to parse rpzrecurse-specific options). Also
fixed various commands to use correct ports.
3. Updates to "clean.sh" scripts to ensure that all files created in the
test are removed.
Stephen Morris [Fri, 17 Nov 2017 13:21:05 +0000 (13:21 +0000)]
[rt46602] Ensure that tests running in parallel use unique ports
Via an intermediate make file, tests that have been modified to be able
to run in parallel are assigned unique query and control port numbers
(other than 5300 and 9953 respectively). Tests that have not yet been
modified all use ports 5300 and 9953, so must be run sequentially.
Petr Menšík [Thu, 22 Feb 2018 14:32:16 +0000 (15:32 +0100)]
unit/unittest.sh is generated by configure. It will always be
generated into builddir. If out-of-tree build is used, make unit
will always fail. Kyuafiles and testdata still have to be copied
manually into the builddir.
Michał Kępień [Tue, 20 Feb 2018 12:59:29 +0000 (13:59 +0100)]
Improve the way cache contents are searched for "ns.flushtest.example"
During the "check flushtree clears adb correctly" check, expecting
"ns.flushtest.example" to always be the first name in the ADB dump is
fragile, because in a certain corner case "a.root-servers.nil" will be
the first name instead.
As the purpose of the relevant check is to ensure "ns.flushtest.example"
is removed from ADB by "rndc flushtree flushtest.example", search the
entire list of names present in ADB instead of just the first entry when
looking for "ns.flushtest.example".
Michał Kępień [Tue, 20 Feb 2018 12:59:28 +0000 (13:59 +0100)]
Wait until a cache dump completes instead of waiting for a fixed amount of time
Dumping the cache is an asynchronous operation, so sleeping for a fixed
amount of time after running "rndc dumpdb" is imperfect as dumping cache
contents may take longer than expected on slower machines. Instead of
always sleeping for 1 second, wait until the "; Dump complete" line
appears in the dump or 10 seconds pass, whichever comes first.
Michał Kępień [Tue, 20 Feb 2018 12:59:27 +0000 (13:59 +0100)]
Do not overwrite cache dumps
Unless configured otherwise in named.conf, "rndc dumpdb" causes a cache
dump to be written to a file called "named_dump.db" in the working
directory of the given named instance. Repeatedly using this command
throughout different checks in the cacheclean system test causes cache
dumps for older checks to be overwritten, which hinders failure
diagnosis. Prevent this by moving each cache dump to a check-specific
location after running "rndc dumpdb".
Furthermore, during the "check flushtree clears adb correctly" check,
dump_cache() is called twice without renaming the resulting files.
Prevent the first cache dump from being overwritten by moving it to a
different file before calling "rndc dumpdb" for the second time.
Michał Kępień [Thu, 15 Feb 2018 19:31:55 +0000 (20:31 +0100)]
Add CHANGES entry
4892. [bug] named could leak memory when "rndc reload" was invoked
before all zone loading actions triggered by a previous
"rndc reload" command were completed. [RT #47076]
Michał Kępień [Thu, 15 Feb 2018 19:31:54 +0000 (20:31 +0100)]
Do not recheck DNS_ZONEFLG_LOADPENDING in zone_asyncload()
Remove a block of code which dates back to commit 8a2ab2b9203, when
dns_zone_asyncload() did not yet check DNS_ZONEFLG_LOADPENDING.
Currently, no race in accessing DNS_ZONEFLG_LOADPENDING is possible any
more, because:
- dns_zone_asyncload() is still the only function which may queue
zone_asyncload(),
- dns_zone_asyncload() accesses DNS_ZONEFLG_LOADPENDING under a lock
(and potentially queues an event under the same lock),
- DNS_ZONEFLG_LOADPENDING is not cleared until the load actually
completes.
Thus, the rechecking code can be safely removed from zone_asyncload().
Note that this also brings zone_asyncload() to a state in which the
completion callback is always invoked. This is required to prevent
leaking memory in case something goes wrong in zone_asyncload() and a
zone table the zone belongs to is indefinitely left with a positive
reference count.
Michał Kępień [Thu, 15 Feb 2018 19:31:53 +0000 (20:31 +0100)]
Asynchronous zone load events have no way of getting canceled
Code handling cancellation of asynchronous zone load events was likely
copied over from other functions when asynchronous zone loading was
first implemented in commit 8a2ab2b9203. However, unlike those other
functions, asynchronous zone loading events currently have no way of
getting canceled once they get posted, which means the aforementioned
code is effectively dead. Remove it to prevent confusion.
Michał Kępień [Thu, 15 Feb 2018 19:31:51 +0000 (20:31 +0100)]
Only clear DNS_ZONEFLG_LOADPENDING in zone_asyncload() if zone loading is completed immediately
zone_load() is not always synchronous, it may only initiate an
asynchronous load and return DNS_R_CONTINUE, which means zone loading
has not yet been completed. In such a case, zone_asyncload() must not
clear DNS_ZONEFLG_LOADPENDING immediately and leave that up to
zone_postload().
Michał Kępień [Thu, 15 Feb 2018 19:31:49 +0000 (20:31 +0100)]
Lock zone before checking whether its asynchronous load is already pending
While this is not an issue in named, which only calls
dns_zone_asyncload() from task-exclusive mode, this function is exported
by libdns and thus may in theory be concurrently called for the same
zone by multiple threads. It also does not hurt to be consistent
locking-wise with other DNS_ZONEFLG_LOADPENDING accesses.