Control: tag -1 patch pending

Cyril Brulebois <cy...@debamax.com> (2023-02-15):
> Seen during upgrade tests, starting at 1.0.9-*: there's an important
> delay (~ 1 minute) during the upgrade, with no apparent activity.

That's 1 minute and 30 seconds, which is the default TimeoutStop(U)Sec
setting.

> According to crowdsec.log, we're waiting for the existing process to
> shut down following the SIGTERM:
> 
>     time="14-02-2023 22:27:53" level=info msg="Crowdsec engine shutting down"

After having checked with upstream, it appears that old versions had
troubles stopping. Trying a SIGTERM outside systemd, I'm seeing this in
the logs:

    time="16-03-2023 20:25:51" level=warning msg="SIGTERM received, shutting 
down"
    time="16-03-2023 20:25:51" level=info msg="Crowdsec engine shutting down"

and more than an hour later, crowdsec still hasn't stopped…

I suppose this was never noticed before because of systemd's default
timeout that ensures this doesn't block forever.

I'm told this is fixed in later versions, and that the fix wasn't
trivial; trying to get it backported to 1.0.* versions could be risky.
Therefore, I plan to mitigate the upgrade delay issue by deploying a
runtime crowdsec.service override, lowering the default timeout from
90 seconds to 20 seconds, when an upgrade from a pre-1.4.x version is
spotted: there's still plenty of time to wrap things up (even on
slow-ish systems), but that means less waiting for everyone during
upgrades…


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Attachment: signature.asc
Description: PGP signature

Reply via email to