systemd-socket-proxyd Can Outlive Its SSH SOCKS Tunnel
Align a socket-forwarding helper's lifecycle with its SSH dependency so a dead tunnel does not leave a healthy-looking front end.
If the front port accepts connections after SSH exits, inspect all three units. The activation socket, systemd-socket-proxyd helper and SSH-created SOCKS listener have distinct lifetimes:
| Socket | Helper | SSH | Interpretation |
|---|---|---|---|
| Listening | Inactive | Inactive | May be waiting normally for demand |
| Listening | Active | Active | Processes exist; onward destination health remains unproven |
| Listening | Active | Inactive | Frontend can accept work without its backend |
Starting the helper and SSH together does not define the later stop transition. For a helper that must not remain active without its tunnel, systemd documents the stronger relationship:
[Unit]
BindsTo=ssh-socks.service
After=ssh-socks.serviceApply it to the appropriate unit in the actual design. Requires= and ordering address only part of the relationship. An already active frontend may otherwise never trigger activation again after its backend disappears. Check failed-unit state and start-rate limits too; dependencies do not override those limits.
Next establish startup readiness. After= orders jobs, not readiness of a Type=simple SSH listener. A fixed sleep can fail during slow authentication. Use a startup contract establishing the required listener; ExitOnForwardFailure=yes catches forwarding-setup failure, not later destination reachability.
Finally, define idle exit and reactivation. The forwarding daemon's idle-exit option concerns no active connections, not a lack of bytes on an open connection. A quiet session can keep it active. The next demand should activate the required services, and restart loops should remain bounded and visible. Recreating the listener admits new connections; it does not restore old proxied TCP sessions.