3 Basic Commands and Simple Shell Scripts Once you have your first Red Hat Enterprise Linux rhel

Download 1.85 Mb.

View original pdf

Page	41/67
Date	26.02.2024
Size	1.85 Mb.
	#63678

1 ... 37 38 39 40 41 42 43 44 ... 67

Pablo Iranzo Gómez, Pedro Ibáñez Requena, Miguel Pérez Colino, Scott McCarty - Red Hat Enterprise Linux 9 Administration-Packt Publishing (2022) -chap 3 82 - 180

User crontab
As with the system-wide crontab, users can define their own crontabs so that tasks are executed by the user. This is, for example, useful for running periodic scripts both fora human user or a system account fora service.
The syntax for user crontabs is the same as it is system-wide. However, the column for the username is not there, since it is always executed as the user is defining the crontab itself.
A user can check their crontab via crontab l, as follows:
[root@rhel-instance
]# crontab -l
no crontab for root
A new one can be created by editing it via crontab -e, which will open a text editor so that anew entry can be created.
Let’s work with an example by creating an entry, like this * * * * date
>>
datecron
When we exit the editor, it will reply as follows:
crontab: installing new crontab
This will create a file in the /var/spool/cron/ folder with the name of the user that created it. It is a text file, so you can check its contents directly.
After sometime (at least 2 minutes, we’ll have a file in our HOME folder that contains the contents of each execution (because we’re using the append redirect that is, >>). You can seethe output here:
[root@rhel-instance
]# cat datecron
Mon Jan 11 21:02:01 GMT 2021
Mon Jan 11 21:04:01 GMT 2021
Now that we’ve covered the traditional crontab, let’s learn about the systemd way of doing things that is, using timers.

Tools for Regular Operations
116
systemd timers
Apart from the regular cron daemon, a cron-style systemd feature is to use timers. A timer allows us to define, via a unit file, a job that will be executed.
We can check the ones that are already available in our system with the following code:
#systemctl list-unit-files *.timer
timers.target static dnf-makecache.timer enabled fstrim.timer disabled systemd-tmpfiles-clean.timer static
Let’s see, for example, fstrim.timer, which is used on solid-state drives (SSDs) to perform a trim at /usr/lib/systemd/system/fstrim.timer:
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
…
[Install]
WantedBy=timers.target
The preceding timer sets a weekly execution for fstrim.service, as follows:
[Unit]
Description=Discard unused blocks
[Service]
Type=oneshot
ExecStart=/usr/sbin/fstrim -av
As the fstrim -av command shows, we are only executing this once.

Learning about time synchronization with chrony and NTP
117
One of the advantages of having the service timers as unit files, similar to the service itself, is that they can be deployed and updated via the /etc/cron.d/ files with the regular cron daemon, which is handled by systemd.
We now know a bit more about how to schedule tasks, but to get the whole picture, scheduling always requires proper timing, so we’ll cover this next.

Download 1.85 Mb.

Share with your friends:

1 ... 37 38 39 40 41 42 43 44 ... 67