I am trying to build a hyperscan-plugin in zeek.
it seems have an issue about muti-thread(i am not sure it is an issue about muti-thread).
I want to print the thread-id info in zeek script when it calling the hyperscan plugin.
I don’t find any about thread-id info that can be print.
I want to know if there are muti-threads runing the same event
Hey Frank,
Script interpretation always happens in the main thread. Zeek is multithreaded for I/O purposes, but not to parallelize event processing. That level of parallelization happens fully via multiple processes. Therefore, if you grab the thread ID from a Zeek script, it’ll always return the main thread’s, where TID = PID. That’s also why there’s only a getpid() built-in function. But if you’d like to experiment, you can easily locate getpid() in zeek.bif and add a thread ID implementation alongside.
You could try something like ps -T -p <pid> to see the thread names and IDs of a given Zeek process.
If you want to verify the local thread, I’d suggest something like gettid() or pthread_self() in the relevant spots in the C++ code.
Say more about your plugin, it sounds fun. 
Best,
Christian
Thanks for your detail description about the thread-things. it is really helping me understand zeek.
I am new to zeek and also hyperscan, I googled that hyperscan has a wonderful performance to do matching packets.
I can write some zeek script to process the tcp content or udp content through event of ‘packet_contents’,
So I build a hyperscan plugin that can read pattern-rules from a file and scan the packet that zeek script give to, this is easy from the example of hyperscan.
So one can use the cmd likes “zeek -Cr xxx.pcap” to check something.
but it seems hyperscan cost much time to compile the rules if you have much rules in files(15K rules in my test case)
i.e. every time runing “zeek -Cr xxx.pcap”, it takes more than 30s(pcap file only has less than 1 hundred packets).
I am wondering if zeek can runing in background and it can be controled by zeekctl to parse one special pcap file.
Thanks! Note that Zeek already has a rules engine. See RuleMatcher and related classes for details, and the signatures tests for examples.
The packet_content event isn’t a good vehicle for signature matching because the event itself has large overhead: Zeek needs to transfer every packet seen into the script layer, which is too expensive for most live-sniffing settings. The event is handy for exploratory or one-off use-cases, usually driven by pcaps.
You’re most likely better off by starting from the existing rule code. That way you can also abstract from packets to the stream level (if desirable).
Best,
Christian