This tested that timers continue working even if one calls
suspend_processing() in zeek -r mode. The new behavior is
that timers do not function in that scenario and the test
invalid.
network_time forwarding will happen in the main-loop before draining the
EventMgr so timers/events scheduled based on broker messages should
behave similarly. This also keeps network_time unaffected during
non pseudo-realtime trace processing.
network_time forwarding will now happen centrally in the main loop.
The TimerMgr returns a valid timeout that can be waited for and will
trigger network_time advancement, so we don't need to do it.
The whole docs read like this was only used to update the
network_time, so there may be a follow-up to ditch EventMgr
even being an IOSource (which could be argued it's not IO).
Add a central place where the decision when it's okay to update network time
to the current time (wallclock) is. It checks for pseudo_realtime and packet
source existence as well as packet source idleness.
A new const &redef allows to completely disable forwarding of network time.
This method will be used by the main loop to determine if an interface
has become idle. Initially this will be used to determine when it is
acceptable to update network_time to the current time (wallclock).
This also removes setting pseduo_realtime to 0.0 in the main loop
when the packet source has been closed. I had tried to understand
the implications it actually seems, if we shutdown the iosource::Manager
anyway, it shouldn't and it's just confusing.
* origin/topic/awelzel/make-some-deprecations-errors:
Expr: Factor out type tag extraction
Var: Add version to deprecated initialization
Stmt: Error on deprecated when/local usage
Expr: Remove vector scalar operations
parse.y: Make out-of-scope use errors
scan.l: Remove unused deprecated_attr
* origin/topic/awelzel/main-loop-allow-multiple-zero-timeouts:
NEWS: main-loop changes around zero-timeout sources
Add a new plugin test with verbose IO source output
iosource: Make poll intervals configurable
iomanager/Poll: Add zero-timeout timeout_src also when there's other events ready
iomanager: Collect all sources with zero timeouts as ready
This is mostly for documentation/verification purposes of how the IO loop
currently does draining and when it picks up FD based (non packet) IO
source. For example, it shows that currently FD based sources are processed
fairly delayed and that we now also process two timeout sources that are ready.
This probably should not be changed by users, but it's useful for
testing and experimentation rather than needing to recompile.
Processing 100 packets without checking an FD based IO source can
actually mean that FD based sources are never checked during a read
of a very small pcap...
This would generally happen the next loop iteration around anyway, but
seems nice to ensure a zero timeout source will be processed at the same
time as sources with ready FDs.
Previously, if two iosources returned 0.0 as their timeout, only
one of them would be considered ready. An always ready source
therefore may starve other ready ones due to this and minimally
this behavior seems surprising.
Offline pcap sources are always ready and return 0.0 for
GetNextTimeout() (unless in pseudo-realtime), so we can
also remove the offline source special case.
One subtle side-effect of this change is that if an IO source
returns a 0.0 timeout *and* it's file descriptor is ready in
the same loop iteration, it may be processed twice.
This has been around since Zeek v4.1, so it was warned about in Zeek 5.0
LTS and we could've removed it with 5.1.
Also removed merge_top_scope() from the zeek::detail namespace, it's
unused now.
Updated the when-aggregates test somehow. I'm not quite sure what had
been tested there :-/
These seem to have been deprecated since 2018, so do it now.
Unfortunately the message didn't contain a version when it'll
be removed, but it's been long enough.
This was marked to be done in Zeek 5.1, so do it now. The message
didn't include a version, unfortunately, but minimally there was
a comment when it should happen.
* origin/topic/timw/update-zeekctl-test-baseline:
ci/centos-stream-8: Add which command
Update zeekctl test baseline for command.peerstatus test
Update zeekctl test baseline for changes to Site::local_nets
Skip building container images (and skip cluster testing)
unless running with fullci.
They don't provide a lot of additional testing coverage, so
should be fine to just run them after merges to master.
There was a misunderstanding whether to include them by default in
the dns.log, so remove them again.
There had also been a discussion and quirk that AD of a request would
always be overwritten by reply in the dns.log unless the reply is
missing. For now, let users extend dns.log themselves for what best
fits their requirements, rather than adding these flags by default.
Add a btest to print AD and CD flags for smoke testing still.
* topic/christian/gh-2761-default-localnets:
Update NEWS to cover new Site::local_nets behavior.
Bump external testsuites to reflect updated baselines
Add btests for new Site::local_nets behavior
Update plugins.hooks baseline to reflect added config framework activity
Update scripts.policy.misc.dump-events baseline
Update btest baselines to reflect the use of local address ranges.
Tighten local-nets filtering in the logging framework's path-func-column-demote test
Fix scripts.policy.frameworks.intel.removal test given address locality info
Treat private address space as site-local by default
Provide a mechanism to suppress logging of internal config framework activity
This test used `Site::is_local_addr()` as part of a filtering criterion, perhaps
unintentionally. The fact that it applied to all tested addresses kept a Zeek
process from exiting, failing the test. It also doesn't need to prioritize its
zeek_init() handler.
