systemd has schedules of its own: timers. They start services and write everything to the journal.
A timer is a unit whose name ends in .timer. It sets the moment to start, and the service of the same name, .service, describes what to do. OnCalendar=daily is every day at midnight, OnActiveSec=5s five seconds after the timer starts. systemd-analyze calendar 'Mon *-*-* 02:15' shows how systemd reads a calendar expression: the next trigger is the coming Monday at 02:15.
A timer is enabled just like a service at the start of the services module: enable starts it at boot, start right now, enable --now both. systemctl list-timers shows each timer's next run (NEXT) and last run (LAST). The service a timer starts is usually short: it does the work and exits, and it stays inactive until the next trigger. Unlike with cron, its output goes to the service's journal.
lab-report.timer is active (waiting), while lab-report.service is inactive (dead) with Result=success. What does that mean?
-
Result=successmeans the service's last run succeeded.inactivemeans it is not running right now: it did its work and exited. -
The timer starts the service, and in such a pair it is the timer you enable. A service without its own
[Install]cannot be enabled anyway:systemctl is-enabledsaysstatic.
A timer's short service does its work and exits, so it is inactive between triggers. systemctl list-timers shows the next run in the NEXT column.
Key points
-
A
.timersets the moment, a.servicedoes the work. -
enableturns the timer on at boot,startright now;systemctl list-timersshowsNEXTandLAST. -
Between triggers the timer's service is
inactive, and that is normal.