What is the difference between a .service and a .timer?

A **`.service`** describes a program: how to start it, who runs it, how to restart it if it crashes, what to do when it exits. A **`.timer`** describes a *schedule* and points at a service to fire. They work together: you write `backup.service` with the actual `ExecStart` and `backup.timer` with `OnCalendar=daily Persistent=true Unit=backup.service`. You enable the **timer** (`systemctl enable --now backup.timer`), not the service: the timer triggers the service whenever the schedule fires. This is the systemd replacement for cron, with better logging, dependencies, and missed-run handling via `Persistent=true`.

Type=simple vs forking vs oneshot, which one do I pick?

Pick by what your program does. **`simple`** (the default for most apps): your program **stays in the foreground**, systemd treats the first `ExecStart` process as the service. Use this for Node, Python, Go web apps, anything that does not daemonize itself. **`forking`**: your program **forks a child and the parent exits** (classic Unix daemons like older nginx, postgres). systemd waits for the parent to exit and tracks the child. You usually need `PIDFile=` too. **`oneshot`**: the command **runs to completion and exits** on purpose (a backup script, a one-time migration). Combine with `RemainAfterExit=yes` if other units should treat the result as "active". **`notify`**: like simple, but your program calls `sd_notify(READY=1)` so systemd knows the exact moment it is ready (best for systems where startup ordering matters). **`idle`**: same as simple but delayed until other boot jobs finish (used for tty-getty). When in doubt, start with `simple`.

Which Restart= policy should I use?

Six options, three you actually need. **`on-failure`**: restart only if the process exits non-zero, is killed by a signal (except SIGTERM/SIGINT/SIGPIPE), times out, or hits the watchdog. This is the **safe default for most web services and workers**. **`always`**: restart no matter why the process exited, including a clean `exit 0`. Use this for **must-stay-alive workers** that should never stop on their own. **`no`**: never auto-restart. Right for **oneshot jobs** (backups, migrations) where finishing successfully is the goal. The rare ones: **`on-success`** (only on clean exit, almost never useful), **`on-abnormal`** (signals and timeouts, but not non-zero exit codes), **`on-watchdog`** (only on watchdog timeout, for `Type=notify` services with `WatchdogSec=`). Pair any restart policy with **`RestartSec=5`** so you do not hammer the system if the program keeps crashing immediately.

How do I harden a service? What are PrivateTmp, ProtectSystem etc.?

systemd ships several free hardening switches that limit damage if the service is compromised. The cheap and useful ones: **`PrivateTmp=yes`** gives the service its own `/tmp` and `/var/tmp` directories, invisible to other processes. **`ProtectSystem=strict`** mounts `/usr`, `/boot`, `/efi`, and `/etc` read-only (use `ReadWritePaths=` to whitelist exceptions). **`NoNewPrivileges=yes`**: the process and its children cannot gain privileges via setuid/setgid binaries (blocks most privilege-escalation paths). **`ProtectHome=yes`** hides `/home`, `/root`, `/run/user`. **`PrivateDevices=yes`**: no access to physical devices. **`ProtectKernelModules=yes`**, **`ProtectKernelTunables=yes`**, **`ProtectControlGroups=yes`** block tampering with the kernel. Run `systemd-analyze security myapp.service` to score your unit on a 0 to 10 scale and see which switches are still off.

How does OnCalendar= syntax work?

OnCalendar uses a compact day-of-week + date + time format, with shortcuts for common cases. **Shortcuts**: `minutely`, `hourly`, `daily`, `weekly`, `monthly`, `quarterly`, `yearly`. **Full form**: `DayOfWeek Year-Month-Day Hour:Minute:Second`. Examples: `*-*-* 02:30:00` runs every day at 02:30, `Mon..Fri 09:00` runs at 09:00 every weekday, `*-*-1 03:00:00` runs at 03:00 on the 1st of every month, `Sat,Sun 10:00` runs at 10:00 on weekends, `*-01,07-01 00:00:00` runs at midnight on January 1st and July 1st. Any field can be `*` (any), a comma list (`Mon,Wed,Fri`), or a range (`Mon..Fri`). To test: `systemd-analyze calendar "Mon *-*-* 09:00"` shows the next run time. To list active timers: `systemctl list-timers`.

What does Persistent= do on a timer?

**`Persistent=true`** tells systemd: if a scheduled run was **missed** because the machine was off, sleeping, or the timer was disabled at the time, **run it as soon as possible after the system comes back up**. Without `Persistent=true`, missed runs are simply skipped: a `daily` timer on a laptop you only open three times a week would fire **three times** instead of once if the laptop was on at the scheduled time, otherwise zero. For backups, reports, cleanups, and anything that **must eventually happen even if late**, set `Persistent=true`. For "every minute" health checks where a stale run is useless, leave it off. The state is tracked in `/var/lib/systemd/timers/`.

Why use RandomizedDelaySec=?

**`RandomizedDelaySec=`** spreads the actual execution time within a window, so many machines running the same timer do not hammer a shared resource at the exact same instant. Concrete case: 500 servers run `OnCalendar=hourly` to pull from a config server. Without randomization, every hour the config server sees 500 simultaneous requests at the top of the hour. With `RandomizedDelaySec=5min`, the requests get spread across a 5-minute window. Also useful for **backups to shared storage** (avoid I/O spikes), **outbound API calls** (stay under rate limits), and **on a fleet of identical hosts** (so log aggregation does not see a hot second). The actual delay is a stable random value per (timer, boot) pair, so the same machine fires at roughly the same offset within the window.

How do I install and enable a unit file? Where does it go?

For **user-installed** services and timers: drop the file in **`/etc/systemd/system/`** (not `/lib/systemd/system/`, that path is owned by packages). Permissions should be `chmod 644 /etc/systemd/system/myapp.service` (root-owned, world-readable). Then: **(1)** `sudo systemctl daemon-reload` so systemd picks up the new file, **(2)** `sudo systemctl start myapp.service` to start it once, **(3)** `sudo systemctl enable myapp.service` to auto-start on boot (this creates the symlink under `multi-user.target.wants/`), or combine both as `sudo systemctl enable --now myapp.service`. For timers, you enable the **timer**, not the service: `sudo systemctl enable --now myapp.timer`. To remove: `sudo systemctl disable --now myapp.service` and delete the file. **Per-user** services go in `~/.config/systemd/user/` and run under `systemctl --user`.

Where are the logs and how do I read them?

When `StandardOutput=journal` (the default, so anything your program writes to stdout/stderr goes to the journal), use **`journalctl -u myapp.service`** to read them. Common flags: **`-f`** follow new lines as they appear (like `tail -f`), **`-n 200`** show the last 200 lines, **`--since "1 hour ago"`** or **`--since today`** filter by time, **`-p err`** show only errors and above, **`-o cat`** plain output without timestamps, **`-r`** reverse (newest first), **`--no-pager`** for scripts. Combine: `journalctl -u myapp.service -f --since "10 min ago"`. For a timer plus service, view both: `journalctl -u myapp.timer -u myapp.service`. The journal is binary, indexed, and rotated automatically: disk usage is capped by `SystemMaxUse=` in `/etc/systemd/journald.conf` (default about 10% of `/var/log/journal` partition).

systemd Unit Builder - free

ModePick .service for a long-running program or .timer for a schedule

PresetsClick to replace the active form

[Unit] - identity & dependencies

Unit nameWithout the extension, e.g. `myapp` becomes `myapp.service`DescriptionShort description shown in `systemctl status` and `systemctl list-units`

AfterUnits that must start before this one. Most commonly `network-online.target`. One entry per line or space-separatedWantsWeak dependency: pull these units along, but do not fail to start if they failRequiresStrong dependency: if a required unit fails to start, this one will not start either

[Service] - execution

Type

How systemd detects that the service has started. `simple` (default) for most apps, `oneshot` for scripts that run and exit, `forking` for daemons that fork to background, `notify` if your program calls `sd_notify(READY=1)`

UserUsername the process runs as. Leave empty = root (usually a bad idea). Create a dedicated user: `sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp`GroupProcess group, defaults to the same as User

WorkingDirectoryWorking directory for the process. Helps with relative paths and finding config filesExecStartFull command with an **absolute path** to the binary. E.g. `/usr/bin/node /var/www/myapp/server.js`. No `cd`, no `&&`, no pipes (use a shell script for that)ExecReloadCommand for `systemctl reload myapp`. Classic: `/bin/kill -HUP $MAINPID`

[Service] - restart policy

Restart

When systemd should restart the process. `on-failure` is the safe default. `always` for workers that must stay alive. `no` for oneshotRestartSecSeconds to wait between restart attempts. 5 is a good minimum so a crash loop does not hammer the system

[Service] - environment variables

[Service] - logging & hardening

StandardOutput

Where stdout/stderr goes. `journal` (default) = `journalctl -u myapp`. Rarely worth changing

PrivateTmp

Gives the service its own `/tmp` and `/var/tmp`. Invisible to other processes. Free hardening, turn it on

ProtectSystem

`yes` = `/usr` and `/boot` read-only, `strict` = entire `/etc` read-only too (strongest). Add `ReadWritePaths=` for directories the service needs to write

NoNewPrivileges

Blocks privilege escalation via setuid/setgid binaries. Should be `yes` for any service that does not need such tricks

[Install]

WantedBy

Which boot target group to attach to. `multi-user.target` for headless servers (95% of cases), `graphical.target` for desktops

/etc/systemd/system/myapp.service

Paste into a systemd unit file

22 lines

[Unit]
Description=Node.js web application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/node /var/www/myapp/server.js
Restart=on-failure
RestartSec=5
Environment="NODE_ENV=production"
Environment="PORT=3000"
StandardOutput=journal
PrivateTmp=yes
ProtectSystem=strict
NoNewPrivileges=yes

[Install]
WantedBy=multi-user.target

Download files

How to install

1. Place the file at /etc/systemd/system/myapp.service
2. sudo systemctl daemon-reload
3. sudo systemctl enable --now myapp.service
4. sudo systemctl status myapp.service
5. journalctl -u myapp.service -f

What is a systemd unit and why use this builder?

On modern Linux (Ubuntu, Debian, Fedora, Arch, Rocky, Alma...) systemd is the program that starts services at boot, restarts them when they crash, and runs scheduled jobs. A unit file is a small text file in `/etc/systemd/system/` that tells systemd *what* to run and *how* to behave.

This builder writes two kinds of units for you:

`.service` ExecStart files for long-running programs (a Node web app, a Python worker, a database).
`.timer` OnCalendar files for jobs that should run on a schedule (the modern replacement for cron).

Pick a preset, fill in the fields, copy the result into a file under `/etc/systemd/system/`, run `sudo systemctl daemon-reload && sudo systemctl enable --now myapp.service`, and you are done. Everything happens in your browser, no upload, no account.

How to use it

Pick a preset that resembles your case (Node web app, Python worker, one-shot backup, database, Go binary, docker compose, static server). The form fills with sensible defaults you can tweak.

Set the unit name (`myapp` becomes `myapp.service`), the Description (shown in `systemctl status`), and the dependencies (After, Wants, Requires, where almost everyone wants `network-online.target`).

In the Service section pick a Type (use `simple` for most apps, `oneshot` for scripts that run and exit, `forking` for daemons that fork to the background), the User and Group to drop privileges, and ExecStart with the absolute path to your binary.

Choose a Restart policy. `on-failure` is the safe default: systemd restarts only if your program exits non-zero or crashes. `always` is for long-lived workers that must come back no matter what. Use RestartSec to set a back-off (5 seconds is fine).

Add Environment variables (NODE_ENV, DATABASE_URL...). Sensitive ones (passwords, tokens) belong in `EnvironmentFile=` instead: put them in a `chmod 600` file outside the unit.

Optional hardening: turn on `PrivateTmp`, `ProtectSystem`, `NoNewPrivileges`. These cost nothing and limit damage if the service is compromised. The builder explains each.

Switch to the .timer tab if you want a scheduled run instead of (or in addition to) the long-running service. Fill in OnCalendar (e.g. `daily`, `Mon *-*-* 03:00:00`), turn on Persistent so a missed run executes after a reboot, point Unit at your service.

Click Copy or Download. Place the file at `/etc/systemd/system/myapp.service` (and `myapp.timer` if applicable), then run `sudo systemctl daemon-reload`, `sudo systemctl enable --now myapp.service`, and watch logs with `journalctl -u myapp.service -f`.

When this is useful

Seven concrete situations where a proper systemd unit saves real time:

You wrote a Node, Python, or Go program and want it to start at boot and restart on crash. Drop a `.service` in `/etc/systemd/system/` and forget about `pm2`, `forever`, `screen`, or `nohup`.
You have a script that should run on a schedule (nightly backup, weekly report, hourly cache refresh). A `.timer` plus `.service` pair is the modern replacement for cron and logs go straight to journalctl.
You need to run a program as a non-root user with controlled permissions. `User=` and `Group=` drop privileges; `ProtectSystem=strict`, `PrivateTmp=yes`, and `NoNewPrivileges=yes` add hardening for free.
You manage a small fleet and want the same service definition across machines. The unit file is plain text: version it in git, deploy with ansible / a Makefile / scp.
You need a service to wait for the network or a database before starting. `After=network-online.target` and `Requires=postgresql.service` make the ordering explicit.
A docker compose stack should start on boot. A oneshot `.service` with `ExecStart=docker compose up -d` plus `Requires=docker.service` handles it cleanly.
You want centralized logs without configuring anything. `StandardOutput=journal` (the default) means `journalctl -u myapp` tails your program and `journalctl --since "1 hour ago"` is your single search.

Questions and answers

systemd is the init system on most modern Linux distributions (Ubuntu since 15.04, Debian since 8, RHEL/CentOS/Rocky since 7, Fedora since 15, Arch, openSUSE...). It is PID 1, the very first process the kernel starts, and it is responsible for booting the system, starting services in the right order, restarting them when they crash, running scheduled jobs (timers), managing devices, mounting filesystems, and collecting logs. When you type `sudo systemctl restart nginx`, you are talking to systemd. A unit file is just a small INI-style text file that tells systemd how to manage one such service, timer, socket, or mount.

[Unit] Description=Node.js web application After=network-online.target Wants=network-online.target [Service] Type=simple User=www-data Group=www-data WorkingDirectory=/var/www/myapp ExecStart=/usr/bin/node /var/www/myapp/server.js Restart=on-failure RestartSec=5 Environment="NODE_ENV=production" Environment="PORT=3000" StandardOutput=journal PrivateTmp=yes ProtectSystem=strict NoNewPrivileges=yes [Install] WantedBy=multi-user.target

What is a systemd unit and why use this builder?

This builder writes two kinds of units for you:

`.service` ExecStart files for long-running programs (a Node web app, a Python worker, a database).
`.timer` OnCalendar files for jobs that should run on a schedule (the modern replacement for cron).

How to use it

Pick a preset that resembles your case (Node web app, Python worker, one-shot backup, database, Go binary, docker compose, static server). The form fills with sensible defaults you can tweak.

Add Environment variables (NODE_ENV, DATABASE_URL...). Sensitive ones (passwords, tokens) belong in `EnvironmentFile=` instead: put them in a `chmod 600` file outside the unit.

Optional hardening: turn on `PrivateTmp`, `ProtectSystem`, `NoNewPrivileges`. These cost nothing and limit damage if the service is compromised. The builder explains each.

When this is useful

Seven concrete situations where a proper systemd unit saves real time:

You wrote a Node, Python, or Go program and want it to start at boot and restart on crash. Drop a `.service` in `/etc/systemd/system/` and forget about `pm2`, `forever`, `screen`, or `nohup`.
You have a script that should run on a schedule (nightly backup, weekly report, hourly cache refresh). A `.timer` plus `.service` pair is the modern replacement for cron and logs go straight to journalctl.
You need to run a program as a non-root user with controlled permissions. `User=` and `Group=` drop privileges; `ProtectSystem=strict`, `PrivateTmp=yes`, and `NoNewPrivileges=yes` add hardening for free.
You manage a small fleet and want the same service definition across machines. The unit file is plain text: version it in git, deploy with ansible / a Makefile / scp.
You need a service to wait for the network or a database before starting. `After=network-online.target` and `Requires=postgresql.service` make the ordering explicit.
A docker compose stack should start on boot. A oneshot `.service` with `ExecStart=docker compose up -d` plus `Requires=docker.service` handles it cleanly.
You want centralized logs without configuring anything. `StandardOutput=journal` (the default) means `journalctl -u myapp` tails your program and `journalctl --since "1 hour ago"` is your single search.

Questions and answers

systemd Unit Builder

What is a systemd unit and why use this builder?

How to use it

When this is useful

Questions and answers

Related tools

SSH Config Builder

Cron expression builder

Nginx Config Snippet Builder

Docker Compose Builder

iptables / nftables Builder

systemd Unit Builder

What is a systemd unit and why use this builder?

How to use it

When this is useful

Questions and answers

Related tools

SSH Config Builder

Cron expression builder

Nginx Config Snippet Builder

Docker Compose Builder

iptables / nftables Builder