What keeps your process running when you close the laptop

The thing people do first, and why it fails

The first deployment nearly everybody performs is this: SSH in, run npm start or python app.py, see the site working, close the terminal. An hour later the site is down.

It is down because the process was a child of your login shell. When the connection dropped, it was sent a hangup signal and died. nohup and tmux fix that particular symptom, and people stop there, which is why so many small sites are one accidental Ctrl-C, one crash, or one reboot away from being offline until somebody notices.

What you actually want is something whose job is to keep your process running: start it at boot, restart it when it exits, and record why it exited. On Linux that is systemd, already installed, and a unit file is about twelve lines.

A unit file, in full

/etc/systemd/system/myapp.service:

[Unit]
Description=myapp
After=network-online.target

[Service]
User=myapp
WorkingDirectory=/srv/myapp
EnvironmentFile=/etc/myapp.env
ExecStart=/usr/bin/node /srv/myapp/server.js
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

enable is the part people forget: without it the service does not come back after a reboot. Restart=always restarts on any exit, including a clean one. Restart=on-failure restarts only on a non-zero exit, which is what you want if the process legitimately finishes.

Anything your program writes to stdout and stderr goes to the journal, timestamped and searchable, with no logging library involved. journalctl -u myapp --since "10 min ago" is the fastest way to answer “what did it say before it died”.

The restart loop that hides the bug

Restart=always will happily restart a process that dies immediately, forever, several times a second. The site looks broken in a way that keeps changing, and the machine gets busy doing nothing.

systemd has a rate limit for this: by default, five starts within ten seconds and it gives up, leaving the unit failed. That is the correct behaviour, and it is worth knowing because “the service will not start and systemctl says failed” often means it started twenty times a minute ago. Tune with StartLimitIntervalSec and StartLimitBurst.

A restart loop is a symptom, not a fix. The journal has the reason, usually in the last two lines before each restart: a missing environment variable, a port already in use, a database that is not up yet.

The killer nobody warns you about

When a Linux machine runs out of memory, the kernel picks a process and kills it. Your application, being the biggest thing on a small box, is nearly always the one picked. It receives no signal it can catch, writes nothing to its own logs, and vanishes.

The evidence lives in the kernel log:

dmesg -T | grep -i -E 'killed process|out of memory'
journalctl -k --since today | grep -i oom

If you see it, the fix is memory (a smaller heap, fewer workers, a bigger box, or a leak found) not a bigger restart limit. Add swap only as a shock absorber; a machine that is swapping is a machine whose latency has already collapsed.

Containers do the same job with different words

In Docker, --restart unless-stopped is Restart=always with a different spelling. In Kubernetes, the restart policy plus liveness probes do it, and CrashLoopBackOff is the same rate limit as above, expressed as an escalating wait.

One container-specific trap: your process becomes PID 1, and PID 1 does not get the kernel’s default signal handling. A process that ignores SIGTERM will sit there until the runtime kills it hard, ten seconds later, mid-request. Running with docker run --init, or handling SIGTERM yourself, avoids it.

The free paths

systemd is free and already on the machine. supervisord is a good, simple alternative if you find unit files unpleasant. pm2 is popular in Node projects and does restarts, log rotation and clustering, but note that it is one more thing that must itself be started at boot, usually by systemd, which is a hint about where the real answer lives.

On a managed platform (Fly, Render, Railway, Cloud Run, a Workers runtime) this lesson is done for you, and the platform’s restart behaviour is worth reading once so you know what it does with a process that will not start.