systemd Service and Timer File Generator
A commented .service and .timer, cron converted to OnCalendar, and units explained.
Try before you buy.
- Free preview: the first lines of the unit files and install commands (up to 20), every count, and the first findings, run times and explained settings (up to 10).
- Locked until you unlock it: download and copy.
- Unlock: Pro pass, ₹179 for 30 days, a one-time payment that never renews.
Ways to unlock shows how to get the full result.
Printing this result is locked in the free preview.
A .service or .timer file. Every setting is explained, and problems are listed.
myapp.service
myapp.timer
Next run times
Findings
Every setting, explained
| Line | Setting | What it does |
|---|
Install and run
Locked in the free preview. Opens the ways to unlock this result.
Locked in the free preview. Batch runs unlock with a pass.
Locked in the free preview. Query results unlock with a pass.
About the systemd Service and Timer File Generator
Fill in how your app or script runs — the command, working directory, user and group, restart policy, environment and environment file, the network dependency and where the logs go — and get a systemd .service file with a comment on every choice, ready for /etc/systemd/system/ (or ~/.config/systemd/user/ for a user service).
To replace a cron job, paste its schedule: the page writes a .timer unit, converts the cron expression to OnCalendar= (two lines when cron’s “either day” rule needs it), and lists the next run times, checked against what cron itself would do. You can also write a calendar event yourself — Mon..Fri *-*-* 07:30, *-*~01 for the last day of the month — and see its normalized form, as systemd-analyze calendar prints it.
Hardening settings are explained one by one — what NoNewPrivileges=, ProtectSystem=, PrivateTmp= and the others protect, and what each can break — with a recommended set and a strict one. The install commands (daemon-reload, enable --now, journalctl -u) are listed for copying. Paste an existing unit to have every setting explained and checked: relative paths, shell syntax in ExecStart=, a missing Wants=network-online.target, settings in the wrong section and deprecated ones.
Without a pass the result is a free preview: the first lines of the files and commands, every count and the first findings. Everything, the copies and the downloads unlock with a Pro pass.
How to use it
- Under Create a unit, give the service a name and the command that starts it. Choose Load example for a web app or a nightly backup to start from a filled-in form.
- Set the user, the working directory, the restart policy, the environment and the logging. Tick Needs the network for a program that connects to anything when it starts.
- For a job on a schedule, open Schedule: paste a cron expression such as
30 2 * * 1-5, or write an OnCalendar= event, and check the next run times. - Pick a hardening set or tick the settings one by one; the explanation under each says what it protects and what it can break.
- With a pass, or once this result is unlocked, copy or download the .service and .timer files and copy the install commands; the preview shows their first lines. To check a unit you already have, use Explain a unit.
Examples
30 2 * * 1-5 (02:30 on weekdays)
OnCalendar=Mon..Fri *-*-* 02:30:00 Persistent=true AccuracySec=1s
Persistent=true runs a job missed while the machine was off; without AccuracySec= a timer may elapse up to a minute late.
0 12 1 * 1 (noon on the 1st and on every Monday)
OnCalendar=Mon *-*-* 12:00:00 OnCalendar=*-*-01 12:00:00
A calendar event needs the weekday and the date to match together, so the schedule takes two lines.
ExecStart=./worker.sh | tee /var/log/worker.log
ExecStart=/bin/sh -c "/opt/worker/worker.sh | tee /var/log/worker.log"
systemd runs the program directly: a pipe is passed as an argument, and the command must start with an absolute path or a bare program name.
Where the rules come from
The settings and their explanations follow the freedesktop.org manual pages: systemd.service(5), systemd.unit(5), systemd.exec(5), systemd.timer(5) and systemd.time(7). The calendar-event parser reproduces the normalized forms of the systemd.time(7) table, and cron conversions were checked against an independent cron implementation, run after run. Run systemd-analyze verify on the file before you rely on it.
Why network-online.target
network.target is reached once networking is being set up, not when it works. A program that must reach a database or an API when it starts should order itself after network-online.target and pull it in — After= alone only orders, Wants= makes systemd actually wait for the network (systemd.special(7)).
Limitations
- The files are written from the form; the page does not run systemd. Check them with systemd-analyze verify and systemd-analyze security.
- Next run times assume the server’s clock is in the time zone you choose (UTC by default). A time that a daylight-saving change skips does not elapse that day, as in systemd (cron runs such a job right after the change); for the hour that repeats when the clocks go back, the page shows the first run only.
- Explaining a unit covers the common [Unit], [Service], [Install] and [Timer] settings; others are listed without an explanation.
Privacy
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
What do I get without a pass?
Without a pass, systemd Service and Timer File Generator shows the first lines of the unit files and install commands (up to 20), every count, and the first findings, run times and explained settings (up to 10). Until you unlock it, the result can’t be downloaded or copied. A Pro, Premium or Ultimate pass, a one-time payment that never renews, unlocks the full result. The pricing page lists the passes and their prices.
Should the service run as root?
Rarely. Create a system user (sudo useradd --system --no-create-home myapp) and set User= and Group=, or use DynamicUser=yes for a service that keeps its data in StateDirectory=. A service that must listen on a port below 1024 can use AmbientCapabilities=CAP_NET_BIND_SERVICE instead of root.
What is the difference between Type=simple and Type=exec?
With simple, systemd counts the service as started as soon as it forks the process, so a wrong path still looks like a successful start. With exec, the start only succeeds once the program has actually been executed, which makes mistakes show up in systemctl start.
Do I still need cron?
Timers can replace cron jobs: they log to the journal, can catch up on runs missed while the machine was off (Persistent=true), run with the hardening of the service, and systemctl list-timers shows when they elapse next.
Is anything uploaded?
No. The files are written in your browser, and units you paste to explain stay there.