A bash entrypoint script sets `trap shutdown TERM` and then runs a long-lived server as its last foreground command. When the supervisor sends SIGTERM, nothing happens until the server exits on its own. Why is the handler delayed, and how do you restructure the script so it runs at once and forwards the signal to the server?

## Why the handler is late Bash's rule is stated plainly in its manual: if the shell is waiting for a command to complete and receives a signal for which a trap has been set, the trap is not executed until the command completes. Signals are noted when they arrive, but the handler is a shell command and the shell only runs shell commands between commands. You can watch it happen in five seconds: ```bash #!/usr/bin/env bash trap 'echo "handler at ${SECONDS}s"' TERM sleep 5 echo "done at ${SECONDS}s" ``` Send SIGTERM one second in and the handler prints at second 5, not second 1 — and the script then carries on and exits 0, because a handler that does not exit simply returns to where the script was. Substitute a real server for `sleep 5` and the orchestrator's grace period expires long before your handler runs; you get SIGKILLed, and the shutdown you carefully wrote never happened. ## Why `wait` is the exception The same manual carves out one case: while the shell is waiting on an asynchronous command via the `wait` builtin, a trapped signal makes `wait` return immediately with a status greater than 128, and the trap then runs. That is the entire mechanism the standard entrypoint pattern rests on. `wait` is the one blocking operation in bash you can interrupt. So the restructure is mechanical: whatever was the blocking foreground command becomes a background job plus a `wait`. ```bash "$@" & child=$! wait "$child" ``` ## Forwarding, and then reaping properly The handler's job is to pass the signal on. The child did not inherit your handler — it does not have one at all unless it installed its own — so nothing reaches it until you send it: ```bash shutdown() { kill -TERM "$child" 2>/dev/null; } trap shutdown TERM INT ``` Now the subtlety that trips people. The first `wait` returned 128+N *without* reaping the child; the child is still shutting down. If you exit at that point you kill your own wrapper while the server is mid-flush, and — worse — you exit with a status you invented. Call `wait` on the same PID again: the second call blocks until the child really ends and yields its true exit status. ```bash rc=0 wait "$child" || rc=$? # 143 the moment the trap fires if [ "$rc" -gt 128 ]; then wait "$child" || rc=$? # now the server's own status fi exit "$rc" ``` Note what strict mode does here: under `set -e`, the first `wait` returning 143 would abort the script before you ever forward anything, which is why the pattern captures the status with `|| rc=$?` rather than letting it fail. ## Exit honestly Whatever supervises this wrapper reads its exit status. A handler that catches TERM, forwards it, and then exits 0 tells the supervisor the run finished cleanly. Propagate the child's status, or re-raise so the wrapper dies the way it was told to: ```bash trap - TERM kill -TERM "$$" # wrapper exits 143, as if it had never trapped ``` ## When not to write any of this All of it exists only because there is a shell sitting between the supervisor and the server. If the wrapper's only remaining job is to run the server, replace the shell with it — the server then receives the supervisor's signals directly, with no forwarding logic to get wrong. Reach for the background-and-wait pattern when the wrapper genuinely must do something after the child stops, or must supervise more than one child. One honest limitation: forwarding to `"$child"` signals that one process. If the server spawns its own children, they are unaffected, and reaching a whole process group is a question about process groups rather than about bash traps.