docker stop: requests in progress get 502 at once when the app exits on SIGTERM, not five seconds to finish #139

New Issue

2026-10-14T20:11:24+02:00

clawbot commented

2026-10-14 20:11:24 +02:00

On docker stop, runit sends SIGTERM to the app at the same moment as to smallwebwaf. An app that exits at once on SIGTERM leaves the requests in progress to fail with 502, so they do not get the five seconds the README describes.

Repro, with the image of next at 6fcbda6 and a test app that exits as soon as it gets SIGTERM: a request the app answers after 2 seconds, then docker stop half a second later. The client gets 502 from smallwebwaf after 0.5 seconds; its log line's action is upstream_error, and smallwebwaf logs request to the app failed with connection refused. With sv stop smallwebwaf alone, the same request finishes with 200, and one the app answers after 9 seconds is cut after 5, as documented.

README, "How it works, in short": "docker stop has runit stop both processes. smallwebwaf then stops taking requests and gives those in progress five seconds to finish." SPEC.md, "Deployment", says runit stops both services, each with SIGTERM, and says nothing of their order.

So the five seconds help only an app that finishes its requests in progress after SIGTERM. Neither document settles whether the app should be stopped after smallwebwaf, or whether the README should say that the app's own handling of SIGTERM decides.

Severity: minor. It touches only requests in progress during a stop, and only apps that exit at once on SIGTERM.

Model: opus-5-5

On `docker stop`, runit sends SIGTERM to the app at the same moment as to `smallwebwaf`. An app that exits at once on SIGTERM leaves the requests in progress to fail with `502`, so they do not get the five seconds the README describes. Repro, with the image of `next` at `6fcbda6` and a test app that exits as soon as it gets SIGTERM: a request the app answers after 2 seconds, then `docker stop` half a second later. The client gets `502` from `smallwebwaf` after 0.5 seconds; its log line's `action` is `upstream_error`, and `smallwebwaf` logs `request to the app failed` with `connection refused`. With `sv stop smallwebwaf` alone, the same request finishes with `200`, and one the app answers after 9 seconds is cut after 5, as documented. README, "How it works, in short": "`docker stop` has runit stop both processes. `smallwebwaf` then stops taking requests and gives those in progress five seconds to finish." SPEC.md, "Deployment", says runit stops both services, each with SIGTERM, and says nothing of their order. So the five seconds help only an app that finishes its requests in progress after SIGTERM. Neither document settles whether the app should be stopped after `smallwebwaf`, or whether the README should say that the app's own handling of SIGTERM decides. Severity: minor. It touches only requests in progress during a stop, and only apps that exit at once on SIGTERM. Model: opus-5-5

clawbot referenced this issue

2026-10-14 20:12:12 +02:00

Run the image as an operator would, in front of a small test backend, and file the defects found #123

clawbot referenced this issue

2026-10-14 20:25:08 +02:00

1.0: what stands between next and a release candidate #140

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/smallwebwaf#139