Need a systemd unit without hunting through man systemd.service? Pick a preset above, set Type, User, and Restart, and copy a .service — plus an optional .timer — for /etc/systemd/system/ or ~/.config/systemd/user/. This systemd service generator stays in your browser. Part of the Linux tools on TechOpt.io. To turn a crontab line into OnCalendar=, use the cron expression builder.
How this systemd service generator builds a unit
A service unit is an INI file with three common sections, as documented in systemd.service. [Unit] is metadata and ordering (Description=, After=, Wants=). [Service] is how the process runs: Type=, ExecStart=, User=, Restart=. [Install] is what systemctl enable hooks into, usually WantedBy=multi-user.target.
Type=simple and Type=exec are for long-running daemons. Type=oneshot is for a command that exits — backups, certbot, a script. Type=forking is for older daemons that daemonize; set PIDFile= so systemd can track the child. Type=notify is for programs that call sd_notify() when they are ready.
System vs user units
System units live in /etc/systemd/system/ and start at boot. They run as root unless you set User=. User units live in ~/.config/systemd/user/ and start when you log in. WantedBy for those is usually default.target. If the job should run without a graphical session, enable lingering: loginctl enable-linger $USER, then use systemctl --user.
Timers instead of cron
A .timer starts a matching .service on a calendar. Enable the timer, not the service: sudo systemctl enable --now backup.timer. This generator omits [Install] from the service when a timer is on so you do not accidentally enable both.
OnCalendar= uses systemd’s calendar syntax (daily, *-*-* 03:00:00, Mon *-*-* 00:00:00). Persistent=true runs a missed job after downtime. systemd ANDs day-of-month with day-of-week, and systemd weekly is Monday — cron @weekly is Sunday midnight. Convert a crontab on the cron builder and paste OnCalendar= here.
Install with daemon-reload
Copy the files into place, then systemctl daemon-reload (or systemctl --user daemon-reload) so systemd rereads the directory. enable --now both enables the unit for future boots and starts it immediately. sudo install -m 644 is enough for unit files; they are not secrets. For the script itself, the chmod calculator will give you a mode such as 755.
Hardening flags
NoNewPrivileges=yes, PrivateTmp=yes, ProtectSystem=strict, and ProtectHome=read-only shrink what the process can touch. They are a good default for a backup script or a daemon that should not write to /usr. Leave them off if the job must update system files or the user’s home directory.
FAQ
Where do systemd unit files go?
Place system units in /etc/systemd/system/ with a .service (and .timer) extension, for example /etc/systemd/system/backup.service. User units go in ~/.config/systemd/user/. Vendor units live under /usr/lib/systemd/; override them with a same-named file in /etc/systemd/system/ instead of editing them. After copying files, run systemctl daemon-reload (or systemctl –user daemon-reload).
Should I enable the service or the timer?
If you generated a timer, enable and start the .timer unit, not the .service. The timer starts the service on the calendar: sudo systemctl enable –now backup.timer. Enabling both can run the job once at boot and again on the schedule. This generator omits [Install] from the service when a timer is on.
What is the difference between a system unit and a user unit?
System units run as root (or a User= you set) and start at boot with multi-user.target. User units run as your login and live in ~/.config/systemd/user/. They start when you log in unless you enable lingering (loginctl enable-linger $USER) so they run without a session. WantedBy for user units is usually default.target, not multi-user.target.
What is Type=simple vs Type=oneshot?
Type=simple (and Type=exec) is for long-running daemons: systemd considers the service started once ExecStart is running. Type=oneshot is for a command that exits — backups, scripts, certbot. Pair oneshot with a .timer instead of Restart=always. Type=forking is for old daemons that daemonize; set PIDFile= so systemd can track the child.
What do NoNewPrivileges and ProtectSystem do?
They are hardening flags. NoNewPrivileges=yes blocks the process from gaining new privileges (setuid). ProtectSystem=strict makes /usr, /boot, and /etc read-only for the service. PrivateTmp= gives it a private /tmp. ProtectHome=read-only hides or read-protects /home. Turn them on for services that should not write to the OS; leave them off if the job must update system files.
Does this systemd generator upload my unit files?
No. It runs entirely in your browser. ExecStart, Environment, and unit names never leave your machine.
Looking for more Linux how-tos? Browse the Linux guides or the rest of the tools.