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