1. 29 Apr, 2021 2 commits
  2. 28 Apr, 2021 6 commits
    • Matthijs Mekking's avatar
      Merge branch 'matthijs-nit-serve-stale-fixes' into 'main' · 51f94b8c
      Matthijs Mekking authored
      Serve-stale nit fixes
      
      See merge request !4940
      51f94b8c
    • Matthijs Mekking's avatar
      Serve-stale nit fixes · 104b6762
      Matthijs Mekking authored
      While working on the serve-stale backports, I noticed the following
      oddities:
      
      1. In the serve-stale system test, in one case we keep track of the
         time how long it took for dig to complete. In commit
         aaed7f9d, the code removed the
         exception to check for result == ISC_R_SUCCESS on stale found
         answers, and adjusted the test accordingly. This failed to update
         the time tracking accordingly. Move the t1/t2 time track variables
         back around the two dig commands to ensure the lookups resolved
         faster than the resolver-query-timeout.
      
      2. We can remove the setting of NS_QUERYATTR_STALEOK and
         DNS_RDATASETATTR_STALE_ADDED on the "else if (stale_timeout)"
         code path, because they are added later when we know we have
         actually found a stale answer on a stale timeout lookup.
      
      3. We should clear the NS_QUERYATTR_STALEOK flag from the client
         query attributes instead of DNS_RDATASETATTR_STALE_ADDED (that
         flag is set on the rdataset attributes).
      
      4. In 'bin/named/config.c' we should set the configuration options
         in alpabetical order.
      
      5. In the ARM, in the backports we have added "(stale)" between
         "cached" and "RRset" to make more clear a stale RRset may be
         returned in this scenario.
      104b6762
    • Michał Kępień's avatar
      Merge branch 'michal/limit-logging-for-verbose-system-tests' into 'main' · 7c7b97b9
      Michał Kępień authored
      Limit logging for verbose system tests
      
      See merge request !4812
      7c7b97b9
    • Michał Kępień's avatar
      Warn when log files grow too big in system tests · 241e85ef
      Michał Kępień authored
      Exerting excessive I/O load on the host running system tests should be
      avoided in order to limit the number of false positives reported by the
      system test suite.  In some cases, running named with "-d 99" (which is
      the default for system tests) results in a massive amount of logs being
      generated, most of which are useless.  Implement a log file size check
      to draw developers' attention to overly verbose named instances used in
      system tests.  The warning threshold of 200,000 lines was chosen
      arbitrarily.
      241e85ef
    • Michał Kępień's avatar
      Prevent useless logging in the "tcp" system test · 17e5c2a5
      Michał Kępień authored
      The regression test for CVE-2020-8620 causes a lot of useless messages
      to be logged.  However, globally decreasing the log level for the
      affected named instance would be a step too far as debugging information
      may be useful for troubleshooting other checks in the "tcp" system test.
      Starting a separate named instance for a single check should be avoided
      when possible and thus is also not a good solution.  As a compromise,
      run "rndc trace 1" for the affected named instance before starting the
      regression test for CVE-2020-8620.
      17e5c2a5
    • Michał Kępień's avatar
      Limit logging for verbose system tests · 4a8d4048
      Michał Kępień authored
      The system test framework starts all named instances with the "-d 99"
      command line option (unless it is overridden by a named.args file in a
      given instance's working directory).  This causes a lot of log messages
      to be written to named.run files - currently over 5 million lines for a
      single test suite run.  While debugging information preserved in the log
      files is essential for troubleshooting intermittent test failures, some
      system tests involve sending hundreds or even thousands of queries,
      which causes the relevant log files to explode in size.  When multiple
      tests (or even multiple test suites) are run in parallel, excessive
      logging contributes considerably to the I/O load on the test host,
      increasing the odds of intermittent test failures getting triggered.
      
      Decrease the debug level for the seven most verbose named instances:
      
        - use "-d 3" for ns2 in the "cacheclean" system test (it is the lowest
          logging level at which the test still passes without the need to
          apply any changes to tests.sh),
      
        - use "-d 1" for the other six named instances.
      
      This roughly halves the number of lines logged by each test suite run
      while still leaving enough information in the logs to allow at least
      basic troubleshooting in case of test failures.
      
      This approach was chosen as it results in a greater decrease in the
      number of lines logged than running all named instances with "-d 3",
      without causing any test failures.
      4a8d4048
  3. 26 Apr, 2021 13 commits
  4. 24 Apr, 2021 2 commits
  5. 23 Apr, 2021 7 commits
  6. 22 Apr, 2021 10 commits