Let's talk about systemd-timers. A systemd-timer is an alternative for a cronjob. And cronjobs
in the past have always been used to start some tasks at a specific moment. Currently,
timers and cronjobs are used side by side, but systemd-timers are slowly replacing cronjobs.
For Red Hat Linux, for instance, you will notice that there is no more default cronjobs.
It's all done by timers if it needs to be done periodically. You can use systemctl listunits
minus t-timer for a list of timers that are currently active. Timers have a matching service
file, and the service file typically has the same name. That is how the timer finds the
matching file. For instance, fstrim.timer works with fstrim.service. And to use timers,
you enable the timer. You don't enable the service. Because you don't want the service
to be running at all time, you want the timer to be running and to trigger the service when
the time is there. So systemctl enable fstrim.timer is what you would be doing. You can consult
man systemd.timer for more details about the timer unit type, and also systemd.time
for more details about the time settings that you can use. Let me show you. So systemctl
listunit files minus t-timer. I'm doing listunit files here, because listunit files normally
gives a little bit more information. And what do we see? Do we have anything interesting?
Well, we can see fstrim.timer. We can analyze what is going on in fstrim.timer. So let's
use systemctl status fstrim.timer, where we can see the unit file that it has loaded.
It's enabled. The preset is enabled, so it was enabled by default. And it's active and
currently waiting. Then we can see a trigger, three days left. And the trigger, so it will
trigger fstrim.service. So systemctl status on fstrim.service is giving me what? It's
only giving me active, inactive, and triggered by fstrim.timer. And the green dot is indicating
that fstrim.timer is indeed listening. So if we check the contents of the timer, fstrim.timer
in systemctl cat, then we see the timer section. And in the timer section, you define how you
want it to be started. So on calendar is weekly. You should do this on a weekly basis. Accuracy
sec is one hour, which means more or less within an hour time frame of the last time
it started. Persistent is true, which means we keep the information about the timer activity
across reboots. And randomized delay seconds, every time we give a 100 minutes randomization.
If you want to know more about the way so you can run a timer, I can really recommend
to have a look at mansystemd.time. Timer is for the unit. Time is for the way how you
can define it. And you get information about timestamps and even about calendar events
right here. So it's very precise in when exactly you want to run it. And if we have a look
at systemd.timer, well, you get some more information about the options. I like table
one here. In table one, we see some interesting options that allow you to run the timer really
in a conditional way. So on active sec means that you are going to run it specific moment
after the timer has been activated. On boot sec means that you are going to run it after
booting. On unit active sec, that's a very nice one that is going to monitor another
unit and is going to run a couple of seconds, minutes, hours, or whatever after that unit
has been activated. So lots of options with your systemd.timer. You can still run crontabs
if you want to. I mean, I can still run crontab minus e student. Sorry, crontab minus e for
the editor minus u student and put something like slash, star slash 10 for every 10 minutes.
If you want to get longer greetings from students, that will still work, but timer has become the
default. So on rel 10, you don't find any crontabs anymore. That will show if you use
ls on etc crontab star dot star. As you can see, it's nearly empty. Timers are the standard nowadays.