Why Does Restart or Shutdown Take Several Minutes (or Hang)?
When KumoMTA shuts down it tries to finish in-flight delivery attempts and flush state to spool before exiting. Open SMTP connections are not killed instantly — each in-flight attempt is allowed to run out its per-phase connection timeouts (connect_timeout, mail_from_timeout, data_timeout, etc.) before it is aborted.
A session stalled against a slow or unresponsive remote is a common cause for delayed shutdown. Idle connections held open for reuse (idle_timeout, default 60s) also have to close during shutdown. Incomplete sends are recovered from the spool on the next start, and no messages are lost.
A shutdown that takes around 5 minutes usually means the systemd stop timeout (TimeoutStopSec) was reached and the process was force-killed. On a correctly configured server you should rarely hit that limit.
What to do
Prefer systemctl stop followed by systemctl start over systemctl restart, especially after rapid successive restarts.
If shutdown regularly hangs, trace the journal in debug mode to find what is still busy just before the SIGKILL. It is typically a misconfiguration or a slow, blocking call in a delivery handler:
Then tune system_shutdown_timeout, which bounds the whole drain. Its default is the sum of the per-message SMTP timeouts (mail_from_timeout + rcpt_to_timeout + data_timeout + data_dot_timeout), so if you have raised any of those connection timeouts you have also raised how long shutdown can take. Set it so the server has enough time to drain in-flight messages cleanly, but not so much that a few stuck connections force every restart to hang.
Note
A long startup (spool enumeration) is a different problem — that one is usually disk-bound. See the troubleshooting guide if startup, rather than shutdown, is slow.