Staying with our common services,
we're going to be taking a look at task scheduling.
Traditionally in UNIX and Linux, we've used the crond to
schedule many of our regular tasks,
but we also have the atd for those tasks that we don't need to run so regularly.
But more recently, we've got systemd timer units,
which can replace many of our cron jobs.
When we're looking at task scheduling, as I say,
we have the crond, and this is used to schedule regular jobs.
Now there might be backups or there might be maintenance
tasks that need to happen on your system.
These can be run by the system,
or individual users can create their own cron jobs if allowed.
When we're looking at tasks that are not required to be run maybe regularly,
then we have the atd.
We can specify a time and date where we need to run a task,
but this is not then for regular tasks; it's more irregular tasks.
So maybe where we want to copy, say,
a couple of terabytes of data from one storage server to another storage server,
it's not going to be done all of the time,
and we want to plan for it out of hours,
so this would make a perfect job for the atd.
Cron jobs are being replaced by systemd timer units.
These are newer, and we don't actually need any additional service to run them.
They are run by process ID 1, our systemd itself.
So with these, they are great for regular tasks.
We're unlikely to create them as ordinary users,
but many of the tasks that we need, say,
for maintenance can be carried out through our timer units.
We're going to be taking a look at all of these,
but to begin with, we're going to start on our AlmaLinux 8 system,
and by taking a look at managing cron jobs,
our traditional job scheduling in Linux.
Now working on the AlmaLinux system, if I go through and list etc/ and cron*,
we'll get an idea of what's set up by default.
Straightaway, we see that we have an etc and crontab file.
This is our main crontab file, where we can create jobs,
schedule tasks for the system to run.
But we also see in the etc directory a cron.deny.
The cron.deny file will list any users who are not
allowed to create their own cron jobs.
By default, this is often empty, so we're not denying anyone.
But you can also probably imagine that we could create a cron.allow file.
If that's empty, then we're not allowing anyone to run their own cron jobs.
So just be very careful about the chron.allow and cron.deny file.
The chron.d directory is an extension directory to the crontab
file, so all of those files added into chron.d are written in
exactly the same format as our crontab file. Whereas when we're
looking at cron.daily, cron.hourly,
cron.monthly and cron.weekly, these directories take scripts,
shell scripts that are executed once an hour,
once a day, once a month, or weekly.
Generally, we don't add anything in there, because if we
put things into the cron.daily directory,
for example, then we don't have really any control over when
that's going to happen, and everything in that directory is going
to execute at the same time each day.
So if we need,
let's say, our backup to run each day, we probably want it to run out of hours,
so we're far better off creating our own cron job to be able to do this.
If I go through and take a look at the system cron file, so
/etc/crontab, when I look inside of this file,
it really is just giving me help of how we configure work.
We should put our own entries inside of the cron.d directory, but for
ease, so we've got the documentation close to our job,
I'm going to leave it in this file and I'm going to do a sudo and vim. Escape
+ dot will bring up my last argument, so it brings up my crontab file again,
and I'm going to hit Enter, capital G will allow me to go to the bottom, and
then I can start putting my entries in.
So I'm going to hit I for insert, and the first field
is we're specifying the minute.
So if I want it to happen at, let's say, quarter after the hour, I
can put in 15. Then we're looking at the hour.
So if I want it, let's say, 9 through to 17,
the 24‑hour clock, this is 9 to 5 during the day. And the day of the
month, so I might put asterisk for any day of the month. And then the
month, so in this case, I'm going to use asterisk for any month of the
year. And then we have the day of the week.
I might want it to run, let's say, Monday to Friday, so 1 through to 5.
We can actually use 0 through to 7, and that's not a mistake. Just saying
that Sunday could be 0 or 7. We specify the username,
so we might say it needs to run as the root account,
and then the command to be executed.
So we could then do, say, df ‑h, send the information
through to /tmp/diskfree or whatever.
If I go through then and save this,
that will then run between 9 and 5 weekdays at a quarter after the hour.
But I have no real reference as to when it last ran or when it next will run.
And that's just the way the crond has been set up.
But also, we can go through and create cron jobs for myself.
So I'm running as a standard user. If I do a crontab and then ‑l, so no
crontab for my vagrant user, crontab ‑e. And then I can go through and
configure it in the same way as we saw before,
so I can then go through and I might do something slightly
different. Whereas, I can go through and say every 15 minutes for
every hour, for every day of the month, for every month,
for every day of the week.
So this is going to run every 15 minutes.
I don't specify in a user cron the user account under which is
going to run. It's always going to run as my account, and then
we can go through and run, yeah, echo hello,
and then send it to our tmp and hello file.
Both of these cases, I'm overwriting the content, so I'm not
going to get excessively large content in any of these files. But
I can then go through and save this.
And again, if I do a crontab ‑l now,
we can go through and see that I have got entries now for the vagrant
user. So this has been our traditional way to schedule tasks, and I
think we'll probably keep it from the user perspective, because
they're relatively easy to create.
But many of our system tasks are going to be replaced through systemd timer units, which we will look at later.