Hi Mika,
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).
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....At least I see an exception related to undefined variables (NoneType)
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:
-- Institute for Common Good Technology http://commongoodtechnology.org/ ZVR 1510673578