Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
systemd organizes Linux services and other system work as units, records activity in its journal, and can schedule recurring jobs with timer units. Use journalctl to inspect service logs, and choose a timer when its calendar- or elapsed-time triggers fit the job; timers handle many cron-like schedules but are not a guaranteed replacement for every cron feature.
What systemd units are
A unit is a named object systemd can manage for boot-up or system maintenance. Services are one familiar unit type, but units can represent different resources or actions. Most are described by unit configuration files; others may be generated from configuration, runtime state, or programmatically.
Unit states include active, inactive, activating, and deactivating. What “active” means depends on the unit type, so it does not always mean a process is continuously running. See the systemd unit documentation for the unit model.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesRequirements and ordering answer different questions
When configuring relationships between units, separate two questions: must another unit be pulled in, and when should the jobs run relative to one another?
#1 Best Overall
Requires=expresses a requirement relationship.After=orBefore=expresses ordering.
A requirement alone does not make the required unit start first. If both units are requested and there is no ordering relationship, systemd may start them in parallel. Use a requirement and an ordering directive when a unit both needs another unit and must run after it.
How to view logs for a systemd service
journalctl prints entries held by the systemd journal that your account is allowed to read. To show entries for a service, run:
journalctl -u name.serviceReplace name.service with the unit name, such as sshd.service. To watch new entries arrive while diagnosing a running service, use:
journalctl -f -u name.serviceWithout arguments, journalctl displays journal records accessible to the caller. Access to system and other users’ journals is permission-controlled; root and members of selected groups, such as systemd-journal, can typically read the system journal. User journals are distinct. The options and access behavior are documented in the systemd 255 journalctl manual; installed versions may differ.
How to see logs from the previous boot
Pass -b -1 to select the previous boot:
journalctl -b -1You can combine boot selection with a unit filter to narrow the results to one service:
journalctl -b -1 -u name.serviceWhether older records are available after a reboot depends on journal storage. journald can use volatile storage or persistent storage; with persistent storage enabled, records can be flushed to /var/log/journal/. Check the machine’s effective Storage= setting and distribution defaults rather than assuming previous-boot logs will be retained. The systemd 252 journald.conf manual describes this behavior; local configuration and distribution defaults matter.
Rank #4
How to create a systemd timer
A timer is a systemd unit that triggers another unit, commonly a service. That keeps scheduled work within systemd’s unit model. The schedule can be based on calendar time or on monotonic elapsed time.
Choose calendar time or elapsed time
| Schedule type | Use it when | What it measures |
|---|---|---|
| Calendar time | The job should run on a wall-clock schedule, such as at a recurring time or date. | Calendar dates and times. |
| Monotonic time | The job should run after an elapsed interval tied to an event or system start. | Elapsed time, rather than a calendar date. |
Timer units support both kinds of trigger. The systemd project’s historical release notes described calendar-timer support as bringing timer events “considerably closer to cron’s capabilities.” That is a useful description of the feature, not a guarantee of complete equivalence with cron.
Best Value
Set up and verify the timer
- Create a service unit for the work you want performed, then create a timer unit that triggers it. The timer is a separate unit, so configure and manage it by its timer-unit name.
- Choose a calendar or monotonic trigger appropriate to the job. Check the timer directives supported by the systemd version installed on the machine; details can vary by version.
- If the job should potentially run after the machine was off at its scheduled time, check whether the timer’s
Persistent=behavior is available and appropriate. The documented behavior saves the last trigger time and may run an overdue event after reboot. It is a possible catch-up run, not a queue of every missed interval. - Enable and start the timer using the system’s normal systemd unit-management workflow, then inspect its unit status and journal entries to confirm its behavior.
Exact timer directives and supported behavior are version-sensitive. Consult the timer manual installed on the target system before relying on a particular schedule or persistence setting.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How a systemd timer differs from cron
Both can schedule recurring work, but they express it differently. A cron entry describes a scheduled command; a systemd timer activates a unit, usually a service. Timers also support monotonic elapsed-time triggers as well as calendar-time triggers, and can participate in systemd’s unit relationships.
| Choice | Best fit | Key distinction |
|---|---|---|
| Calendar timer | A job tied to a calendar date or wall-clock time. | Uses systemd timer units and activates a unit. |
| Monotonic timer | A job tied to elapsed time after an event or system start. | Measures elapsed time rather than a calendar schedule. |
| Cron entry | A job scheduled through cron’s own mechanism. | Do not assume every cron feature has a direct timer equivalent. |
Persistent timer behavior can help with an event missed while the machine was powered off, but it does not replay every missed occurrence. For version-specific details, check the timer documentation provided with the installed systemd release.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
