# &expire\_func/&create\_expire question

**URL:** <https://community.zeek.org/t/expire-func-create-expire-question/1058>\
**Category:** Zeek\
**Created:** [November 17, 2006, 9:18pm UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058 "2006-11-17T21:18:09Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mike\_Wood](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@Mike\_Wood](https://community.zeek.org/u/Mike_Wood)\
**Post date:** [November 17, 2006, 9:18pm UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/1 "2006-11-17T21:18:09Z")

</div>

Hiya,

Below is a script that I would think should cause the &expire\_func to execute, but doesn't. (I would expect the expire function to execute assuming you run the script on a trace that has packets with arrival times separated by more than EXPIRE time, which is set to 1 second below).

---

<div class="post-metadata">

**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\
**Post date:** [November 17, 2006, 10:51pm UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/2 "2006-11-17T22:51:03Z")

</div>

Hey Mike,

mhmmm sorry but this seems to work here. For comparison, does this more  
basic one give you output?

---

<div class="post-metadata">

**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\
**Post date:** [November 18, 2006, 12:37am UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/3 "2006-11-18T00:37:15Z")

</div>

We have some progress on the non-triggering of the expiration callback.  
It is triggered, but a \*long\* time after the &create\_expire interval.  
Below are the timings using a 20 minute trace for this code:

function expire(t: table[count] of count, idx:count): interval  
{  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print fmt("%s %s (expire)", current\_time(), network\_time());  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return 0 sec;  
}

global state: table[count] of count &create\_expire=1sec &expire\_func=expire;  
global idx: count = 0;

event new\_packet(c: connection, p: pkt\_hdr)  
{  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;++idx;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;state[idx] = idx;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print fmt("%s %s", current\_time(), network\_time());  
}

---

<div class="post-metadata">

**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\
**Post date:** [November 18, 2006, 12:43am UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/4 "2006-11-18T00:43:34Z")

</div>

> Real time is out, since 1s hasn't yet passed. But network time has  
> advanced 91s before I see the callback!?

Timer expiration is driven off of packet arrivals. Is there a lengthy  
lull in arriving packets that causes the 91 second delay?

&nbsp;&nbsp;&nbsp;&nbsp;Vern

---

<div class="post-metadata">

**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\
**Post date:** [November 18, 2006, 1:39am UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/5 "2006-11-18T01:39:45Z")

</div>

Uh-oh. I've discovered that packets in that trace were not in  
chronological order, sorry. So I switched to one that covers ~3 minutes,  
definitely sorted and without substantial gaps, and now the delay is at  
60s, when a burst of expirations is triggered.

I've uploaded the stdout output I get with that trace and the below code  
at [http://www.cl.cam.ac.uk/~cpk25/bro/expiration-log.txt.gz](http://www.cl.cam.ac.uk/~cpk25/bro/expiration-log.txt.gz) .

---

<div class="post-metadata">

**Author:** ![Christian\_Kreibich3](https://avatars.discourse-cdn.com/v4/letter/c/4af34b/32.png) [@Christian\_Kreibich3](https://community.zeek.org/u/Christian_Kreibich3)\
**Post date:** [November 18, 2006, 1:55am UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/6 "2006-11-18T01:55:55Z")

</div>

Another factoid: for \*any\* &create\_expire delay between 1s and 60s  
(inclusive) the first expiration is triggered at exactly the same time,  
1039100508.06149. Once it's at 61 seconds, the first expiration is at  
1039100568.33063 -- pushed back by another minute.

Cheers,  
Christian.

---

<div class="post-metadata">

**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:** [November 20, 2006, 7:31pm UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/7 "2006-11-20T19:31:54Z")

</div>

To clarify how table expiration works: we do not install an  
individual timer for every table entry; that would way too many.  
Instead, every table gets \*one\* timer which periodically triggers  
the expiration of all outdated entries. By default, this is done  
every 10s (table\_expire\_interval). Furthermore, when entries are  
expired, only 5000 (table\_incremental\_step) are expired in a row,  
then a delay of 0.01 (table\_expire\_delay) is inserted to avoid  
dropping packets.

Robin

---

<div class="post-metadata">

**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:38pm UTC](https://community.zeek.org/t/expire-func-create-expire-question/1058/8 "2022-05-06T15:38:02Z")

</div>


