Git clean in GitLab CI can take up to a thousand lines, thus cluttering
the output for no good reason.
The default GitLab GIT_CLEAN_FLAGS variable is extended with "q" as in
"quiet.
(cherry picked from commit ddb33a12fc)
The serve-stale system test was intermittently failing due to a timing
issue:
I:serve-stale:check stale data.example TXT was refreshed...
I:serve-stale:failed
The RRset is refreshed, however, it first checks for an expected log
line, prior checking that the stale data.example TXT was refreshed
(using dig). This log line is there to ensure the record is actually
refreshed before we start querying again. Alternatively we could just
retry_quiet 10 <wait for dig output matches expectations>. It would
lower the chances for intermittent test failures, since there is no
longer a "check for log line, sleep one second if check fails, check
for log line, ...", prior to the check.
(cherry picked from commit 0bf36da305)
Avoid creating any temporary files in the current workdir.
Additional/changing files in the bin/tests/system directory are
problematic for pytest/xdist collection phase, which assumes the list of
files doesn't change between the collection phase of the main pytest
thread and the subsequent collection phase of the xdist worker threads.
Since the testcrypto.sh is also called during pytest initialization
through conf.sh.common (to detect feature support), this could
occasionally cause a race condition when the list of files would be
different for the main pytest thread and the xdist worker.
(cherry picked from commit 61330a7863)
Previously, an AXFR request would be issued every second while waiting
for the zone to be signed. This might've been the cause of issues in CI
where many tests are running in parallel and any extra load may increase
test instability.
Instead, check for the last NSEC record to have a signature before
commencing the AXFR request to check the zone has been fully signed.
Also increase the time for the zone signing to a total of 60+10 seconds
up from the previous 30.
(cherry picked from commit 3291c891f6)
There's no point in continuing the dupsigs test if a failure is
detected. End the test early to avoid wasting time and resources.
(cherry picked from commit ad647dca13)
Ensure messages from dupsigs system test end up in its log rather than
stdout. Previously, the output was hard to debug when running the tests
in parallel and messages wouldn't end up in the dupsigs.log.
(cherry picked from commit cbe2559f37)
In v9.16, the number of expected signatures for the fully signed dupsigs
zone is 1009 rather than 1008, since there is one extra DNSKEY
signature. The test itself checks for the correct number, but the
barrier which waits for the zone to be fully signed doesn't.
In practice, this had the effect of always waiting the full 30 seconds
for the zone to be signed. Afterwards, the wait barrier would fail.
However, the return code isn't handled, so the test would proceed and
succeed anyway, since 30 seconds was enough time for the zone to get
fully signed.
This issue was introduced during a backport in commit
4840d6f9c9.
The instance-wide GitLab CI artifact retention time was changed to 1 day
up from the previous value of 12 hours. Remove our explicit overrides
for 1 day artifact retention time, as it is the default now.
Previously, most of our jobs had overrides for 1 day retention, while
some of our jobs used the default 12 hours. This discrepancy could be
quite impractical at times.
(cherry picked from commit 8fef5676fa)
If the zone already has existing NSEC/NSEC3 chains then zone_sign
needs to continue to use them. If there are no chains then use
kasp setting otherwise generate an NSEC chain.
(cherry picked from commit 4b55201459)
The dnstap system test fails intermittently, and it appears to be
a timing issue - adding a short delay after running 'fstrm_capture',
and before running 'dnstap -reopen' improves the situation from
50% failures (5 out of 10 times) to 0% failures (0 out of 20 times),
tested locally.
The reason is that 'fstrm_capture' is executed in the background,
and due to OS scheduling and other factors, the listener socket
may not be ready when the following command runs and tells 'named'
to (re)open it.
(cherry picked from commit fa686fcea5)
BUILD_PARALLEL_JOBS environmental variable is set to 6, which does not
align well with 4 and 8 CPU core systems dedicated to CI "stress" tests.
When multiple parallel jobs run on the host, they compete for resources
with an undesirable result: 6 compiler processes of one job may starve
named, resulting in lower-than-expected throughput and minutes-long
query response latency spikes.
Better drop the build parallelism of BIND-under-test. About 1-2 minutes
are added to the 60-65 minutes long job duration.
(cherry picked from commit 3fd7e7c81f)
By omission, BIND was not built with common CFLAGS in the stress test
jobs. Building with common CFLAGS and -Og should help GDB produce a
backtrace with more information.
(cherry picked from commit d33bdd36b4)
In the generated man pages, `@RELEASEDATE@` wasn't replaced since the
actual variable name is `RELEASE_DATE` with an underscore. This issue
was introduced in the recently merged !7518 (commit
18b7ba3ea3) which removed the pregenerated
man pages from the repo.
The Known Issues section for 9.16.38 release notes was accidentally
removed during branch maintenance after release. Restore the contents to
its tagged released version.
Named now logs both compile time and run time UV versions when
starting up. This is useful information to have when debugging
network issues involving named.
(cherry picked from commit 5fd2cd8018)
Remove the part which is no longer true after reverting the commit
in question.
The CHANGES entry was never part of a released BIND 9 version.
(cherry picked from commit e1627e1289)
This reverts commit 1254f37584.
The commit introduced a data race, because dns_db_endload() is called
after unfreezing the zone.
(not cherry picked from commit 593dea871a)
Michal Nowak
Matthijs Mekking
Tom KrizekandMichal Nowak
Mark Andrews
Arаm Sаrgsyаn