Hi Mika,
On 6/22/22 1:58 PM, Mika Silander wrote:
Tracking down a rather elusive bug led me to suspect that the command
intelmqctl reload your_bot_name_here
does not necessarily rerun the bot's init method.
It does, but not directly.
reloading relies on sending a signal to the process. But signals interrupt system calls, which is normally not an issue, except the process is currently doing something on the network, more specifically with the pipeline (sending or receiving data). Let's assume that the bot sends an event to redis, get's interrupted. What to do now? Run init, and then? we can't just resume the previously running process() call. Therefore, the behaviour is not completely straighforward, but not magic. The signal is caught (__handle_sighup_signal) and python is commanded to resume system calls instead of interrupted (signal.siginterrupt(signal.SIGHUP, False) in __init__) Once there is time to handle the reload safely (before/after process, during sleeps, when waiting for messages), the bot is actually reloaded and __init__ called (__handle_sighup).
At least I see an exception related to undefined variables (NoneType)
In the code of the core or in the bot's code? If it's the bot's code: What bot is it? In any case, the stacktrace helps in explaining the issue, because unfortunately crystal ball broke last night when my neighbors' dragon chased my little dinosaur....
when I reload the bot in question and let it chew a new event. Is this expected behaviour? Still, skimming through the code, it seems to me that the __init__ method in lib/bot.py gets invoked and should invoke the bot's init method as well.
Yes, it shoud/does:
https://github.com/certtools/intelmq/blob/79cae294a74ab77f09b1f371a19f04ad65...