fix(gateway): exit 0 on systemctl stop instead of exit 1 (failed unit)

[liuhao1024]

Summary

When the gateway runs under systemd and receives SIGTERM (e.g. from systemctl stop), it exits with code 1, leaving the unit in "failed" state. This requires systemctl reset-failed before a clean restart and pollutes any health monitoring that reads unit state.

Root Cause

The signal handler treats any SIGTERM without a planned-stop marker as an unexpected kill. But systemctl stop is a deliberate operator action that sends SIGTERM without writing a marker first.

The exit-1 rationale is self-defeating: the installed unit uses Restart=always, under which exit 0 is also restarted. So a non-zero exit buys nothing for revival — it only converts a clean stop into a "failed" unit.

Fix

In gateway/run.py, the signal handler now checks if the gateway is running under systemd (via INVOCATION_ID env var or ppid == 1) and the received signal is SIGTERM. If so, it treats it as a planned stop → exit 0 → unit goes "inactive" instead of "failed".

This preserves the exit-1 behavior for:

• Non-systemd environments (standalone, Docker without systemd)
• Any signal that is NOT SIGTERM under systemd (future-proofing)

Testing

• 8 new tests in tests/gateway/test_systemd_stop_exit_code.py
• Tests cover: under_systemd detection with/without INVOCATION_ID, signal discrimination (SIGTERM vs SIGINT), and the decision-logic condition
• Existing test_clean_shutdown_marker.py passes (no regression)

Reproduce → Expected Behavior

Before:

hermes gateway install && hermes gateway start
systemctl --user stop hermes-gateway-<name>
systemctl --user is-active hermes-gateway-<name>  # → "failed"

After:

hermes gateway install && hermes gateway start
systemctl --user stop hermes-gateway-<name>
systemctl --user is-active hermes-gateway-<name>  # → "inactive"

Closes #41631

[alt-glitch]

Likely duplicate of #41639 — both fix #41631 by treating SIGTERM under systemd as a planned stop (exit 0) in gateway/run.py so the unit reports "inactive" instead of "failed". Same root cause, same call site.

[liuhao1024]

Thanks for flagging @alt-glitch. I've left a comparison on #41639 — this PR (#41642) uses the existing snapshot_shutdown_context() infrastructure with under_systemd detection and has 8 tests exercising the actual context function, while #41639 replicates the logic inline with os.environ.get() and 4 tests. Both fix #41631 equivalently. Keeping this one open as the more complete fix.

[teknium1]

Thanks for addressing the real failed-unit symptom.

Problems

• gateway/run.py:19911 treats under_systemd as evidence that systemd sent the signal. It only establishes the process environment: an external kill -TERM against a systemd-managed gateway takes the same branch and is incorrectly classified as planned. Current main intentionally treats only SIGINT or a consumed planned-stop marker as planned (gateway/run.py:20611-20623), preserving the unexpected-signal path (gateway/run.py:20652-20660, 20920-20925).
• tests/gateway/test_systemd_stop_exit_code.py:71-76 reimplements the condition instead of exercising shutdown_signal_handler and its exit result.

Suggested changes

• Rework this around the existing marker mechanism: generate a non-recursive systemd ExecStop helper that writes the planned-stop marker for $MAINPID before systemd sends SIGTERM. This is the direction documented in #42517 and implemented by open PR #42555.
• Test the real handler path for both marked systemctl stops and unmarked external SIGTERM.

Automated hermes-sweeper review.

[teknium1]

under_systemd says only that this process was launched by systemd; it does not identify the SIGTERM sender. An external kill -TERM of this process matches this branch and is then treated as a clean stop. Preserve the existing marker-based distinction instead, ideally by writing the marker from the generated unit's ExecStop path.

[teknium1]

This duplicates the proposed predicate rather than exercising shutdown_signal_handler, so it cannot verify the real flag or exit-code behavior. Please test the handler path and include an unmarked external SIGTERM while the process is systemd-managed.