A process you started by hand in a terminal dies when you close the terminal. Keeping it alive means handing it to the system's service manager. Here is how — plus one discipline that outranks the technique: automatic restarts hide problems.
In this pagewhat service-ising buys you, two routes, the traps, restart discipline. Not in this pagemy service names, unit files or log paths. All placeholders.
| Benefit | Without it |
|---|---|
| Start at boot | After a reboot (provider maintenance, kernel update) your thing never came back, and nobody told you |
| Restart on crash | One transient crash equals permanent stop |
| Logs with a home | Output scattered in a terminal, gone when closed; nothing to investigate later |
| One way to start/stop/check | Every service with its own startup ritual; in three months you will not remember any of them |
The first is the most underrated: a cloud machine will reboot. Not "might" — host maintenance, kernel patches, your own slip. It happens a few times a year.
| The tool's own install command | Writing your own unit | |
|---|---|---|
| How | e.g. hermes gateway install (add --system for boot start) | Hand-write a unit file |
| Upside | It knows what it needs — paths, variables, ordering | Full control |
| Downside | You do not know what it wrote for you | Easy to miss the environment (below) |
| Advice | Use it if it exists | When there is none, or you need different behaviour |
Hermes's documentation warns explicitly:
do not add a drop-in like ExecStopPost=/bin/kill -9 — it causes an infinite restart loop.
The general lesson: a service that manages its own process should not be wrapped in process management of yours. The classic symptom of two layers fighting is "it keeps restarting and the logs never explain why" — because nothing survives long enough to write it.
Same phenomenon as the scheduler trap: services start in a minimal
environment — short PATH, none of your shell config, and a working directory that is not the one
you assumed.
Symptom: works fine by hand, "command not found" or "config not found" as a service. Same fixes: absolute paths, set variables explicitly, set the working directory explicitly.
| User | System | |
|---|---|---|
| Privilege | That user's, smaller | Larger |
| Boot start | ⚠ Usually needs an extra switch, otherwise it waits for that user to log in | Starts at boot |
| Advice | Default to this — least privilege | When boot start or a low port is genuinely required |
A user service by default starts only after that user logs in. Reboot the machine and the service is not up — but SSH in to check and there it is, running (because you just logged in). The illusion passes casual verification easily.
Verify properly: reboot, do not log in, and confirm from outside that the service responds.
A service crashing every 30 seconds and being restarted every 30 seconds reads as "active" from outside. You might not notice for months.
And in those months? Possibly dropping whatever it was processing on each restart, possibly repeating actions that should have happened once, possibly burning money on retries.
Two disciplines:
① monitor the restart count itself — not "is it alive" but "how many times did it restart today";
② set a restart ceiling: after N consecutive failures in a short window,
stop trying and let it stay down.
A service that is clearly dead beats one that is pretending to be alive.
| Do | Why |
|---|---|
| Send to the system log, or a fixed file | There has to be one definite place to look |
| Set rotation and size caps | Otherwise the disk fills eventually (page 19) |
| Never log secrets | Logs usually have looser permissions and get backed up. Common leak path |
hermes gateway install (user scope),
sudo hermes gateway install --system (system scope, boot start),
hermes gateway start / stop / status; launchd plist on macOS.
The docs explicitly warn against adding ExecStopPost=/bin/kill -9-style drop-ins (infinite restarts).
Official docs, checked 2026-08-21.