Stream: git-wasmtime

Topic: wasmtime / issue #14935 discuss: should graceful shutdown...

Wasmtime GitHub notifications bot (Oct 22 2026 at 13:18):

xia-chao opened issue #14935:

SIGTERM is graceful now (#14904), and a second signal short-circuits. But if a component never returns, the first signal waits forever. Worth bounding it?

Wasmtime GitHub notifications bot (Oct 22 2026 at 13:27):

xia-chao edited issue #14935:

SIGTERM is graceful now (#14904), and a second signal short-circuits. But if a component never returns, the first signal waits forever. Worth bounding it?

<details>
<summary>Additional information</summary>

Current behavior

wasmtime serve has handled SIGTERM through the graceful shutdown path since #14904. Requests that are already in flight are allowed to complete, and a second signal short-circuits the wait and terminates the process.

There is no upper bound on that wait. If a component's handler does not return — for example, it loops without yielding, blocks on a future that never resolves, or waits on a host call that never completes — the first SIGTERM leaves the process waiting indefinitely. Termination then depends on a second signal, or on the process supervisor.

Why this can matter

Process supervisors eventually escalate to SIGKILL, so the process does not survive forever. However, the observable stop latency is then determined by the supervisor's configured timeout (TimeoutStopSec for systemd, --timeout/-t for docker stop, default 10s), not by wasmtime serve. During that interval, systemctl stop, docker stop, and equivalent orchestration operations report the service as stopping without making progress. Tooling that sends a single SIGTERM and waits for exit without a fallback signal will block.

Possible directions

1. Status quo. Treat the second signal as the documented escape hatch and rely on the supervisor's SIGKILL for a hard bound. No code change.
2. Opt-in bounded shutdown. Add --shutdown-timeout <duration> (disabled by default). When set, the graceful phase is bounded: if in-flight requests have not completed by the deadline, the process exits anyway.
3. Alternative mechanism. Reuse an existing timeout facility (for example, the per-request -W timeout) or introduce a deadline at the request level instead of the process level.

Open questions for option 2

• Should the option be off by default, so existing deployments keep the current behavior?
• What should the exit status be when the deadline forces termination: success (0), or a distinct non-zero code for "shutdown timed out"?
• What should happen to in-flight requests at the deadline: connection reset, or a best-effort error response?
• How should the deadline interact with the second-signal short circuit and with --shutdown-addr?
• Should the deadline be logged, and at what level?

Compatibility and performance

With the option disabled by default, no existing behavior, configuration, or exit status changes. Enabling it adds one timer for the shutdown path only, so request-path performance is unaffected.

Testability

The condition is reproducible with a component that never returns from its handler; the tree already contains test programs for this shape (for example p3_cli_serve_sleep). A test can send one SIGTERM while a request is in flight, assert that the process does not exit before the configured deadline, and assert that it exits after it.

</details>

Wasmtime GitHub notifications bot (Oct 22 2026 at 20:46):

alexcrichton commented on issue #14935:

Subjectively I'd say this isn't worth it for a debugging-style utility of wasmtime serve unless someone has a more pressing need for it

Last updated: Oct 31 2026 at 23:03 UTC