Job systemd-service-restarts-and-logs-one-process · revised 11 October 2026
Run one process as a systemd service that restarts itself and logs
One long-running process starts at boot, restarts after a crash within limits you set, runs as its own user and writes logs you can read, with the unit file tested.
You might be seeing
- The process was started by hand over SSH and stops when the session closes
- After a server reboot the process is not running until someone starts it
- The process crashes and nobody can see why, or its output file grows without limit
No passwords, keys, card details or admin invites needed to start.
What usually happened
A process started by hand or from cron has no supervisor: nothing restarts it, nothing starts it at boot, it often runs as the wrong user, and its output is lost or piles up in a file. systemd can supervise it, but its defaults restart nothing, the start type decides when a start counts as successful, and restart rate limits stop a service that crashes immediately from restarting for ever.
Who it’s for: A developer or founder whose worker, bot or API runs in a terminal session or from cron on a Linux server, and stops when the session ends or the process crashes.
Usually starts when: The process dies overnight, does not come back after a reboot, or nobody can find its output.
The result: One process is managed by a systemd unit that starts at boot as a non-root user, restarts after a failure, stays stopped when you stop it, and writes its output to the journal. Killing the process or rebooting the server shows it come back; stopping it by command shows it stay stopped.
Check whether this job fits
Four checks that decide whether this fixed job fits. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Confirm systemd and see what runs today
These only read. The second lists services that are already running, so you can see whether yours is one of them.
systemctl --version; systemctl list-units --type=service --state=runningLook for: A version line, and whether your process appears. A hand-started process will not appear in the service list.
What you get
- The unit file and any drop-in file, with the install and removal steps
- A test transcript for kill, stop, reboot and the crash-loop limit
- A one-page runbook: status, logs, start, stop, and clearing a failed state
Included
- One long-running process (a worker, queue consumer, bot or API) on one Linux server that uses systemd
- A unit file with the user, working directory, start command, restart policy and delay, start-rate limits and, only if the process needs the network up when it starts, both Wants=network-online.target and After=network-online.target
- An environment file for non-secret settings, and the agreed route for any secret
- Journal logging with the commands to read it, and optional basic confinement settings the process tolerates
- Tests of kill, stop, reboot and repeated immediate failure, and a short runbook
Not included
- Finding or fixing the bug that makes the process crash
- Several interdependent services or containers: use the Compose job for those
- Monitoring, alerting or paging when the service fails
- Shipping logs to an outside service, or log rotation for files the process writes itself
- Moving the process to another server or changing the application code
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
After the main process is killed with SIGKILL through systemctl, a new process is running within the restart delay plus ten seconds, and the journal shows both the failure and the restart.
Evidence: Process IDs before and after, the service status and the journal lines. The command signals only the unit's main process and reports an error, without signalling anything else, if the unit is not running.
sudo systemctl kill --signal=SIGKILL --kill-whom=main app.service; sleep 15; systemctl is-active app.serviceAfter stopping the unit with the stop command, it stays inactive for at least 60 seconds, and the start command brings it back.
Evidence: Status output at the start and end of the 60 seconds, then after the start command.
After a reboot, the unit is active without anyone logging in, and the working check passes.
Evidence: Boot time, the enabled and active status, and the working check result.
A copy of the unit that exits immediately is restarted no more than the agreed burst count within the agreed interval, then shows as failed. Clearing the failed state lets it start again.
Evidence: Journal lines for each attempt, the failed status and the output after clearing it.
The process runs as the named non-root user in the named working directory, and its output appears in the journal for the unit.
Evidence: The process listing and journal lines.
The unit file passes systemd's own verification, and if it orders after the network it contains both Wants=network-online.target and After=network-online.target.
Evidence: The verification output (empty when nothing is wrong) and the Unit section of the file.
systemd-analyze verify /etc/systemd/system/app.service
Sign-off. You sign off after the kill, stop, reboot and crash-loop tests pass on your server. Payment follows sign-off.
If it fails. If an agreed test fails and cannot be fixed within the scope, you do not pay for this fixed scope and you keep the unit file and findings. If the process cannot be supervised safely, we say why and stop.
When it fits, and when we stop
It fits when
- The server runs systemd 240 or later (the exec start type was added in 240) and you can run commands as an administrator
- The process runs in the foreground, or you can describe how it forks and where it writes its process ID
- You can name the user it should run as and a command that shows it is working
- A slot to stop and start the process, and to reboot a test or low-traffic server, with a provider console to reach the server if it does not come back
We stop and tell you if
- The process needs an interactive terminal or a desktop session
- It must run as root and nobody can say why
- The host does not use systemd
- The server runs systemd older than 240 and the older start type is not acceptable to you
- Starting it twice would corrupt data and there is no way to prevent a second copy from running
What could go wrong
Stopping and disabling the unit and deleting its file returns the server to how it was. The process you started by hand can be started the old way again, so nothing depends on the unit existing.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A restart loop hides a crash and floods the logs. | Set a restart delay and start-rate limits so the unit ends up failed and visible, and test that behaviour with a deliberately failing copy. |
| A confinement setting stops the process writing a file it needs. | Apply confinement settings one at a time, keep only those that pass the working check, and list those that were tried and removed. |
| Secret values end up in the unit file, which anyone on the server can read. | Keep secrets out of the unit and read them from a protected file or a credential, as agreed. |
An independent reviewer reads the unit for the user it runs as, the restart and rate-limit settings, any confinement setting that might break the process, and how secret values are supplied.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the process, its user, its working directory, the working check and the test window in writing
- Write the unit on a copy of the same operating system release and choose the start type that matches how the process behaves
- Set the restart policy, delay and start-rate limits with you, and send output to the journal
- Independent review of the unit, especially the user, any confinement settings and how secrets are read
- Hand over the files and steps, then run the kill, stop and crash-loop tests with a second session kept open
- Run the reboot test in the window you approve and record the result
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
To have the server patched and its services reviewed each month, ask about the monthly server patch and review service. This job does not include monitoring.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- The systemd.service manual documents every restart option and start type if your team wants to write the unit itself. man.archlinux.org
- If the app already runs in a container, a Compose restart policy may be simpler than a unit file.
Questions
Why not run it from cron or a terminal multiplexer?
Those can start a process, but they do not restart it or keep its output in one place. systemd is already on the server, and where the process needs the network it can be ordered after it.
Will it restart for ever if it crashes immediately?
No. Restarts are subject to start-rate limits. When the limit is hit the unit is left failed until it is cleared or started by hand.
Does this fix my crash?
No. It restarts the process and records the failure. Finding the cause is a separate bug-fix job.
Can I use Docker instead?
Yes, if the process already runs in a container. A restart policy in Compose then does the same job.
Send an enquiry
Send us
- The command and arguments used to start it today, with secrets removed
- How you know it is working: a URL, a log line or a command
- The user and directory it should run under, and the operating system release
- Do not send passwords, keys or server logins in the first enquiry
Later, once you agree
- A copy or test server running the same operating system release, or a time-limited administrator account that you create and revoke
- The non-secret environment variables, and the route for any secret values
- A window to stop, start and reboot the machine
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the server, the process and its data. We write and test the unit file on a copy of your server's operating system release and hand you the files. You install them, or you create a time-limited, least-privilege account for that and revoke it afterwards, agreed in writing. Secrets stay with you.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “systemd-service-restarts-and-logs-one-process” as the subject.