# Scheduling events are immediatly executed **URL:** \ **Category:** Zeek\ **Created:** [December 8, 2015, 3:35pm UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934 "2015-12-08T15:35:24Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Jan\_Muthreich](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@Jan\_Muthreich](https://community.zeek.org/u/Jan_Muthreich)\ **Post date:** [December 8, 2015, 3:35pm UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934/1 "2015-12-08T15:35:24Z")
Hello, I'm working with BRO and have a problem. I want to use scheduling but it doesn't seem to work. Alle tests, that I wrote, are immidiatly ready. I have seen the ticket [https://bro-tracker.atlassian.net/browse/BIT-747](https://bro-tracker.atlassian.net/browse/BIT-747) and have tried to reschedule. But it doesn't work. The rescheduled event is either missing, when no files are read, or immidiatly ready when files are read. Have someone tipps for me or is there any documentation, how the scheduling and eventing are work in BRO? For example this is the test I use: #@TEST-EXEC: bro -b -C -r $TRACES/10000.pcapng %INPUT \> output 2\> output.err #@TEST-EXEC: test -f output #@TEST-EXEC: btest-diff output #@TEST-EXEC: test -f output.err #@TEST-EXEC: btest-diff output.err event e2() {   print "e2"; } function scheduleEvent(){   print "f1";   schedule 100sec { e2() }; } event e1() {   print "e1";   scheduleEvent(); } event bro\_init() {   schedule 100sec { e1() }; } The trace file can be any pcap file. consistec Engineering & Consulting GmbH Jan Muthreich - Software Engineer ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [December 8, 2015, 4:23pm UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934/2 "2015-12-08T16:23:03Z")
One thing to keep in mind for schedule is that it's relative to "network time", i.e., the packet timestamps in the trace. When you say 100s, it's not going to wait for 100s of wall clock time to pass, but will trigger the event once the packet timestmaps have covered 100s. When working offline from a trace, like in your case, that often feels like "immediately" if the input is short. Could that be it? Robin ---
**Author:** ![Jan\_Muthreich](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@Jan\_Muthreich](https://community.zeek.org/u/Jan_Muthreich)\ **Post date:** [December 9, 2015, 7:51am UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934/3 "2015-12-09T07:51:42Z")
Thank you. I have an Input READER\_ASCII in use, which need Input::force\_update. It reads from a linux pipe. How can we schedule this operation if no network traffic is in the line? Mit freundlichen Grüßen Jan Muthreich ---
**Author:** ![Dirk\_Leinenbach](https://avatars.discourse-cdn.com/v4/letter/d/7ea924/32.png) [@Dirk\_Leinenbach](https://community.zeek.org/u/Dirk_Leinenbach)\ **Post date:** [December 10, 2015, 4:21pm UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934/4 "2015-12-10T16:21:22Z")
Hi all, is Bro's event schedule depending on "input" from the network / trace file? I.e., does it stop processing ASCII reader input if there's no more network activity? This might not be a big deal in production rollouts when bro is listing to real network interfaces, but in test scenarios (with btest) it looks to me as if bro stops processing other input, once the pcap files have been consumed completely. Is there any work around / best practice on how such situations can be handled in tests? Thanks for your help! Dirk ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [December 10, 2015, 8:33pm UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934/5 "2015-12-10T20:33:30Z")
Bro normally terminates once it has read the whole trace. You can prevent that by setting exit\_only\_after\_terminate to true; then it will keep running (and proecessing other input) until you call the built-in function terminate(). You can see this in the input framework tests in testing/btest/scripts/base/frameworks/input. The other piece to this (and the original question) is that it's a fundamental challenge to process a trace while also doing things that happen in real-time (input framework, but also any communication with external processes). Bro can read a trace much more quickly than it would normally process the same traffic during live operation, meaning it will get out of sync with any other activity still happening "just" in real time. There's a work-around for testing purposes: Bro has a switch "--pseudo-realtime" that articifially delays processing a trace: after reading each packet, it inserts a delay corresponding to the timestamp gap to the next packet. In that way, it "simulates" real-time processing by not getting head of what a live Bro would do. For example, the test testing/btest//scripts/policy/protocols/ssl/validate-certs-cluster.bro uses this to set up a Bro cluster of multiple processes for X509 cert validation while reading the input from a trace. Robin ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:43pm UTC](https://community.zeek.org/t/scheduling-events-are-immediatly-executed/3934/6 "2022-05-06T15:43:16Z")