mirror of https://github.com/KumoCorp/kumomta.git synced 2026-10-28 08:00:38 +00:00

Files

T

Wez Furlong 3b14587192 fix delayed shutdown for non-smtp delivery handlers

Occasionally we'll have someone report that systemd timed out
and sigkill'd their kumo on shutdown.

One possible scenario for this is a lua delivery handler that
is taking too long, presumably because the other end of it
(eg: webhook or other custom endpoint) is not responding in
a timely fashion.

The way that we handle shutdown is that we compute a maximum
theoretical timeout value by summing up all of the smtp client
timeout values.  Some of those can be several minutes in
duration because the are using default values derived from
a very conservative set of values suggested by the SMTP
RFCs from the '70s.

Those obviously should not apply to a custom delivery handler,
but also, in the context of an established SMTP session, we
should not add in the connection-establishment-specific values
when we're just waiting for a per-message send.

This commit addresses this situation on two fronts:

* Introduce a new system_shutdown_timeout value that allows the
  user to conveniently express their desired timeout value
  in a single option.  This is *not* set by default!
* The default value for system_shutdown_timeout is computed by
  summing the per-message-delivery smtp timeout options, which
  is a much more reasonable, and more importantly, shorter than
  our 300s TimeoutStopSec value in kumomta.service

2025-04-02 14:21:31 -07:00

604 B

Raw Blame History

system_shutdown_timeout

How long to wait for an in-flight delivery attempt to gracefully complete when the system is being shutdown. Once this timeout is reached, any open sessions will be aborted.

The default value is computed by summing up the per-message-delivery timeout values:

!!! caution If you make this value too short you increase the risk duplicate delivery when the sessions are terminated.

604 B Raw Blame History

system_shutdown_timeout

604 B

Raw Blame History