#1867 fix markdown violation in automation folder (#1975)

docs/guides/automation/anacron.md

@@ -5,22 +5,22 @@ contributors: Steven Spencer, Ganna Zhyrnova
 update : 2021-10-20
 ---
 
-#  `anacron` - Run Commands Regularly
+# `anacron` - Run Commands Regularly
 
-##  Prerequisites
+## Prerequisites
 
-* A computer running Rocky Linux.
-* Know how to use your favorite editor to change the configuration file (such as *vim*) in the command line environment.
-* Understand basic RPM package management.
+- A computer running Rocky Linux.
+- Know how to use your favorite editor to change the configuration file (such as *vim*) in the command line environment.
+- Understand basic RPM package management.
 
-##  Assumptions
+## Assumptions
 
-* You have the basic knowledge of bash, python or other scripting or programming tools, and want to run the script automatically.
-* You connected in as the root user, or switch to root with `su - root`.
+- You have the basic knowledge of bash, python or other scripting or programming tools, and want to run the script automatically.
+- You connected in as the root user, or switch to root with `su - root`.
 
-##  `anacron` Introduction
+## Introduction
 
-**`anacron` runs commands on a regular basis, and the operating frequency is defined in units of days. It is suitable for computers that do not run 24/7, such as laptops and desktops. Suppose you have a scheduled task (such as a backup script) to be run in the early morning of every day using crontab. When you fall asleep, your desktop or notebook is off. Your backup script will not run. However, if you use `anacron`, you can rest assured that the next time you turn on the desktop or notebook, the backup script will run.**
+`anacron` runs commands on a regular basis, and the operating frequency is defined in units of days. It is suitable for computers that do not run 24/7, such as laptops and desktops. Suppose you have a scheduled task (such as a backup script) to be run in the early morning of every day using crontab. When you fall asleep, your desktop or notebook is off. Your backup script will not run. However, if you use `anacron`, you can rest assured that the next time you turn on the desktop or notebook, the backup script will run.**
 
 The appearance of `anacron` is not to replace `crontab`, but to complement `crontab`. Their relationship is as follows:
 
@@ -45,6 +45,7 @@ shell > rpm -ql cronie-anacron
 ```
 
 First check the default configuration file:
+
 ```bash
 shell > cat /etc/anacrontab
 # /etc/anacrontab: configuration file for anacron
@@ -75,7 +76,8 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin
 MAILTO=root
 01 *  *  *  * root run-parts /etc/cron.hourly
 ```
-```
+
+```bash
 shell > journalctl -u crond.service
 - Logs begin at Wed 2021-10-20 19:27:39 CST, end at Wed 2021-10-20 23:32:42 CST. -
 October 20 19:27:42 li systemd[1]: Started Command Scheduler.
@@ -86,7 +88,6 @@ October 20 20:01:01 li CROND[1897]: (root) CMD (run-parts /etc/cron.hourly)
 October 20 21:01:01 li CROND[1922]: (root) CMD (run-parts /etc/cron.hourly)
 October 20 22:01:01 li CROND[1947]: (root) CMD (run-parts /etc/cron.hourly)
 October 20 23:01:01 li CROND[2037]: (root) CMD (run-parts /etc/cron.hourly)
-
 ```
 
 For more configuration file information, [browse the manual page](https://man7.org/linux/man-pages/man5/anacrontab.5.html)
@@ -95,7 +96,6 @@ For more configuration file information, [browse the manual page](https://man7.o
 
 To make certain files run within these automatically defined times, all you need to do is to copy the script file to the relevant directory and verify that it has **execution permission (chmod +x)**. Therefore, you only need to let the system automatically run the script at one of these scheduled times, which simplifies the automation task.
 
-
 Let us use cron.daily to illustrate the run process of /etc/anacrontab:
 
 1. `anacron` reads the **/var/spool/anacron/cron.daily** file, and the content of the file shows the time of the last run.

docs/guides/automation/cron_jobs_howto.md

@@ -13,28 +13,28 @@ tags:
 
 ## Prerequisites
 
-* A computer running Rocky Linux
-* Some comfort with modifying configuration files from the command-line by using your favorite editor (using `vi` here)
+- A computer running Rocky Linux
+- Some comfort with modifying configuration files from the command-line by using your favorite editor (using `vi` here)
 
-## <a name="assumptions"></a> Assumptions
+## Assumptions
 
-* Basic knowledge of bash, python, or other scripting or programming tools, and you want to have a script run automatically
-* That you are running as the root user or have the ability to `sudo -s`  
+- Basic knowledge of bash, python, or other scripting or programming tools, and you want to have a script run automatically
+- That you are running as the root user or have the ability to `sudo -s`  
 **(You can run certain scripts in your own directories as your own user. In this case, switching to root is not necessary.)**
 
 ## Introduction
 
-Linux provides the _cron_ system, a time-based job scheduler, for automating processes. It is simplistic and yet quite powerful. Want a script or program to run every day at 5 PM? This is where you set that up.
+Linux provides the *cron* system, a time-based job scheduler, for automating processes. It is simplistic and yet quite powerful. Want a script or program to run every day at 5 PM? This is where you set that up.
 
-The _crontab_ is essentially a list where users add their own automated tasks and jobs, and it has many options that can simplify things even further. This document will explore some of these. It is a good refresher for those with some experience, and new users can add the `cron` system to their toolbox.
+The *crontab* is essentially a list where users add their own automated tasks and jobs, and it has many options that can simplify things even further. This document will explore some of these. It is a good refresher for those with some experience, and new users can add the `cron` system to their toolbox.
 
 Discussed briefly here is `anacron` in reference to the `cron` "dot" directories. `cron` runs by `anacron`, and is helpful for machines that are not up all the time, such as workstations and notebooks. The reason for this is that while `cron` runs jobs on a schedule, if the machine is off at the scheduled job time, the job does not run. With `anacron` the job will run when the machine is on again, even if the scheduled run was in the past. `anacron` though, uses a more randomized approach to running tasks where the timing is not exact. This makes sense for workstations and notebooks, but not for servers. This can be a problem for things such as server backups, for instance, needing to run a job at a specific time. That is where `cron` provides the best solution for server administrators. Still, server administrators and workstation or notebook users can gain something from both approaches. You can mix and match based on your needs. For more on `anacron` see [anacron - Automating commands](anacron.md).
 
-### <a name="starting-easy"></a>Starting easy - the `cron` dot directories
+### Starting easy - the `cron` dot directories
 
 Built into every Linux system for many versions now, the `cron` "dot" directories help to automate processes quickly. These show up as directories that the `cron` system calls based on their naming conventions. These run differently, however, based on the process assigned to call them, `anacron` or `cron`. The default behavior is to use `anacron`, but this is changeable by a server, workstation or notebook administrator.
 
-#### <a name="for_servers"></a>For servers
+#### For servers
 
 As stated in the introduction, `cron` normally runs `anacron` these days to run scripts in these "dot" directories. You *may* want to use these "dot" directories on servers as well, and if that is the case, it requires two steps to verify that these "dot" directories run on a strict schedule. To do this, you need to install a package and remove another one:
 
@@ -46,7 +46,7 @@ and
 
 As you might expect, this removes `anacron` from the server and reverts to running tasks within the "dot" directories on a strict schedule. `/etc/cron.d/dailyjobs` is the file that controls the schedule, which has the following contents:
 
-```
+```bash
 # Run the daily, weekly, and monthly jobs if cronie-anacron is not installed
 SHELL=/bin/bash
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
@@ -60,18 +60,18 @@ MAILTO=root
 
 This translates to the following:
 
-* run scripts in `cron.daily` at 04:02:00 every day.
-* run scripts in `cron.weekly` at 04:22:00 on Sunday every week.
-* run scripts in `cron.monthly` at 04:42:00 on the first day of every month.
+- run scripts in `cron.daily` at 04:02:00 every day.
+- run scripts in `cron.weekly` at 04:22:00 on Sunday every week.
+- run scripts in `cron.monthly` at 04:42:00 on the first day of every month.
 
-#### <a name="for_workstations"></a>For workstations
+#### For workstations
 
 If you want to run scripts on a workstation or notebook in the `cron` "dot" directories, you need not do anything complicated. Copy your script file into the directory in question, and ensure it is executable. Here are the directories:
 
-* `/etc/cron.hourly` - Scripts placed here will run one minute past the hour every hour (run by `cron` regardless of whether `anacron` exists or not)
-* `/etc/cron.daily` - Scripts placed here will run every day. `anacron` adjusts the timing of these (see tip)
-* `/etc/cron.weekly` - Scripts placed here will run every 7 days, based on the calendar day of the last run time (see tip)
-* `/etc/cron.monthly` - Scripts placed here will run monthly based on the calendar day of the last run time (see tip)
+- `/etc/cron.hourly` - Scripts placed here will run one minute past the hour every hour (run by `cron` regardless of whether `anacron` exists or not)
+- `/etc/cron.daily` - Scripts placed here will run every day. `anacron` adjusts the timing of these (see tip)
+- `/etc/cron.weekly` - Scripts placed here will run every 7 days, based on the calendar day of the last run time (see tip)
+- `/etc/cron.monthly` - Scripts placed here will run monthly based on the calendar day of the last run time (see tip)
 
 !!! tip
 
@@ -91,7 +91,7 @@ If the automated, randomized times do not work well in [For Workstations above](
 
 This will pull up root user's `crontab` as it exists at this moment in your chosen editor, and might look something like this. Read this commented version, as it has descriptions of each field that you will use next:
 
-```
+```text
 # Edit this file to introduce tasks to be run by cron.
 #
 # Each task to run has to be defined through a single line
@@ -119,17 +119,17 @@ This will pull up root user's `crontab` as it exists at this moment in your chos
 
 Notice that this particular `crontab` file has some of its own documentation built-in. That is not always the case. When modifying a `crontab` on a container or minimalist operating system, the `crontab` will be an empty file unless an entry is in it.
 
-Assume that you have a backup script that you want to run at 10 PM at night. The `crontab` uses a 24 hour clock, this would be 22:00. Assume that you backup script is "backup" and that it is currently in the _/usr/local/sbin_ directory.
+Assume that you have a backup script that you want to run at 10 PM at night. The `crontab` uses a 24 hour clock, this would be 22:00. Assume that you backup script is "backup" and that it is currently in the */usr/local/sbin* directory.
 
 !!! note
 
     Remember that this script needs to also be executable (`chmod +x`) in order for the `cron` to run it.
 
-To list the present jobs running 
+To list the present jobs running
 
 `crontab -l`
 
-To list all jobs created by user 
+To list all jobs created by user
 
 `crontab -l -u <username>`
 
@@ -139,13 +139,13 @@ To add the job, you:
 
 `crontab` stands for "cron table" and the format of the file is, in fact, a loose table layout. Now that you are in the `crontab`, go to the bottom of the file and add your entry. If you use `vi` as your default system editor, you will do this with the following keys:
 
-<kbd>SHIFT</kbd>+<kbd>:</kbd>+<kbd>$</kbd>
+++shift+colon+"$"++
 
 Now that you are at the bottom of the file, insert a line and enter a brief comment to describe what is going on with your entry. You do this by adding a "#" to the beginning of the line:
 
 `# Backing up the system every night at 10PM`
 
-Hit <kbd>ENTER</kbd>. You should still be in the insert mode, so the next step is to add your entry. As shown in our empty commented `crontab` (above) this is **m** for minutes, **h** for hours, **dom** for day of month, **mon** for month, and **dow** for day of week.
+Hit ++enter++. You should still be in the insert mode, so the next step is to add your entry. As shown in our empty commented `crontab` (above) this is **m** for minutes, **h** for hours, **dom** for day of month, **mon** for month, and **dow** for day of week.
 
 To run our backup script every day at 10:00, the entry looks like this:
 
@@ -157,12 +157,12 @@ This says run the script at 10 PM, every day of the month, every month, and ever
 
 Another way to run jobs at a strictly scheduled time (i.e., day, week, month, year, and so on.) is to use the @options, which offer the ability to use more natural timing. The @options consist of:
 
-* `@hourly` runs the script every hour of every day at 0 minutes past the hour (this is exactly the result of placing your script in `/etc/cron.hourly` too).
-* `@daily` runs the script every day at midnight.
-* `@weekly` runs the script every week at midnight on Sunday.
-* `@monthly` runs the script every month at midnight on the first day of the month.
-* `@yearly` runs the script every year at midnight on the first day of January.
-* `@reboot` runs the script on system startup only.
+- `@hourly` runs the script every hour of every day at 0 minutes past the hour (this is exactly the result of placing your script in `/etc/cron.hourly` too).
+- `@daily` runs the script every day at midnight.
+- `@weekly` runs the script every week at midnight on Sunday.
+- `@monthly` runs the script every month at midnight on the first day of the month.
+- `@yearly` runs the script every year at midnight on the first day of January.
+- `@reboot` runs the script on system startup only.
 
 !!! note
 
@@ -192,9 +192,9 @@ When determining when to run a script, you need to take time and plan it out, pa
 
 ## Conclusions
 
-The _cron/crontab_ system is a powerful tool for the Rocky Linux systems administrator or desktop user. It allows you to automate tasks and scripts so that you do not have to remember to run them manually. More complex examples are here:
+The *cron/crontab* system is a powerful tool for the Rocky Linux systems administrator or desktop user. It allows you to automate tasks and scripts so that you do not have to remember to run them manually. More complex examples are here:
 
-* For machines that are **not** on 24 hours a day, explore [anacron - Automating commands](anacron.md).
-* For a concise description of `cron` processes, check out [cronie - Timed Tasks](cronie.md)
+- For machines that are **not** on 24 hours a day, explore [anacron - Automating commands](anacron.md).
+- For a concise description of `cron` processes, check out [cronie - Timed Tasks](cronie.md)
 
 While the basics are not difficult, the options can be more complex. For more on `crontab` head up to the [crontab manual page](https://man7.org/linux/man-pages/man5/crontab.5.html). On most systems, you can also enter `man crontab` for additional command details. You can also do a web search for "crontab" which will give you a wealth of results to help you fine-tune your `crontab` skills.