Signal server ignores SIGTERM and skips its shutdown on docker stop

[chad-loder]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Relay / Signal / NAT traversal, Self-hosting / Deployment

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Linux, Docker

NetBird version and upgrade status

• Signal: 0.77.0
• Upgrade status: not yet on 0.80.0; the code is unchanged on main (signal/cmd/root.go, SetupCloseHandler).

Did this work before?

Not sure

Regression details

No response

Summary

The signal server's shutdown handler registers only os.Interrupt (SIGINT): signal.Notify(c, os.Interrupt) in signal/cmd/root.go, under a comment that says it handles SIGTERM. SIGTERM, which docker stop, systemd and Kubernetes send by default, is not caught, so the process is terminated without running its shutdown path. Management, relay, the combined server and the client all register syscall.SIGTERM; signal is the only one that does not.

Current behavior

On SIGTERM the signal process ends at once. The shutdown in run.go (closing the gRPC, HTTP and certificate listeners, shutting down the metrics server, logging stopped Signal Service) does not run. signal/Dockerfile.ubi compensates with STOPSIGNAL SIGINT; signal/Dockerfile does not, so docker stop on the standard image sends SIGTERM.

Expected behavior

SIGTERM triggers the same shutdown as SIGINT, as in the other services, and the comment matches the code.

Steps to reproduce

1. Run the signal server (netbird-signal run ...).
2. Send SIGTERM (kill -TERM <pid>, or docker stop on a container from signal/Dockerfile).
3. The process exits without the stopped ... log lines that SIGINT produces.

Environment and topology

Signal in its own container. The behavior does not depend on topology.

Self-hosted details, if available

No response

Logs, status output, or debug evidence

With SIGINT the log ends with stopped HTTP server, stopped metrics server, stopped Signal Service; with SIGTERM none of these appear.

Related issues or discussions

None found.

Possible change

Add syscall.SIGTERM to the signal.Notify call in SetupCloseHandler and correct its comment (and the Ctrl+C pressed message), matching relay's and management's handlers. The impact today is small, since peers reconnect after a restart either way, but the standard image currently skips its own shutdown on every docker stop. I'd be happy to put up a PR once the approach is accepted.

[hippi345]

Confirmed on current main. SetupCloseHandler in signal/cmd/root.go (L54-64) still does signal.Notify(c, os.Interrupt) only, under a comment that says it handles SIGTERM. The standard signal/Dockerfile (distroless, ENTRYPOINT ["/go/bin/netbird-signal","run"]) has no STOPSIGNAL, so docker stop sends SIGTERM. Go's default SIGTERM action kills the process before stopCh is ever written, so the listener/metrics shutdown never runs.

Until the one-line fix lands (signal.Notify(c, os.Interrupt, syscall.SIGTERM)), you can get the clean path today by sending SIGINT instead:

• compose: stop_signal: SIGINT on the signal service
• plain docker: docker stop --signal SIGINT <ctr> (or docker run --stop-signal SIGINT ...)
• systemd: KillSignal=SIGINT in the unit

That's the same thing Dockerfile.ubi does with STOPSIGNAL SIGINT.