Chapter 24. Automating System Tasks
Chapter 24. Automating System Tasks You can configure Red Hat Enterprise Linux to automatically run tasks, also known as jobs : regularly at specified time using cron , see Section 24.1, "Scheduling a Recurring Job Using Cron" asynchronously at certain days using anacron , see Section 24.2, "Scheduling a Recurring Asynchronous Job Using Anacron" once at a specific time using at , see Section 24.3, "Scheduling a Job to Run at a Specific Time Using at" once when system load average drops to a specified value using batch , see Section 24.4, "Scheduling a Job to Run on System Load Drop Using batch" once on the boot, see Section 24.5, "Scheduling a Job to Run on Boot Using a systemd Unit File" This chapter describes how to perform these tasks. 24.1. Scheduling a Recurring Job Using Cron Cron is a service that enables you to schedule running a task, often called a job, at regular times. A cron job is only executed if the system is running on the scheduled time. For scheduling jobs that can postpone their execution to when the system boots up, so a job is not "lost" if the system is not running, see Section 24.3, "Scheduling a Job to Run at a Specific Time Using at" . Users specify cron jobs in cron table files, also called crontab files. These files are then read by the crond service, which executes the jobs. 24.1.1. Prerequisites for Cron Jobs Before scheduling a cron job: Install the cronie package: The crond service is enabled - made to start automatically at boot time - upon installation. If you disabled the service, enable it: Start the crond service for the current session: (optional) Configure cron . For example, you can change: shell to be used when executing jobs the PATH environment variable mail addressee if a job sends emails. See the crontab (5) manual page for information on configuring cron . 24.1.2. Scheduling a Cron Job Scheduling a Job as root User The root user uses the cron table in /etc/crontab , or, preferably, creates a cron table file in /etc/cron.d/ . Use this procedure to schedule a job as root : Choose: in which minutes of an hour to execute the job. For example, use 0,10,20,30,40,50 or 0/10 to specify every 10 minutes of an hour. in which hours of a day to execute the job. For example, use 17-20 to specify time from 17:00 to 20:59. in which days of a month to execute the job. For example, use 15 to specify 15th day of a month. in which months of a year to execute the job. For example, use Jun,Jul,Aug or 6,7,8 to specify the summer months of the year. in which days of the week to execute the job. For example, use * for the job to execute independently of the day of week. Combine the chosen values into the time specification. The above example values result into this specification: 0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * Specify the user. The job will execute as if run by this user. For example, use root . Specify the command to execute. For example, use /usr/local/bin/my-script.sh Put the above specifications into a single line: Add the resulting line to /etc/crontab , or, preferably, create a cron table file in /etc/cron.d/ and add the line there. The job will now run as scheduled. For full reference on how to specify a job, see the crontab (5) manual page. For basic information, see the beginning of the /etc/crontab file: Scheduling a Job as Non-root User Non-root users can use the crontab utility to configure cron jobs. The jobs will run as if executed by that user. To create a cron job as a specific user: From the user's shell, run: This will start editing of the user's own crontab file using the editor specified by the VISUAL or EDITOR environment variable. Specify the job in the same way as in the section called "Scheduling a Job as root User" , but leave out the field with user name. For example, instead of adding add: Save the file and exit the editor. (optional) To verify the new job, list the contents of the current user's crontab file by running: Scheduling Hourly, Daily, Weekly, and Monthly Jobs To schedule an hourly, daily, weekly, or monthly job: Put the actions you want your job to execute into a shell script. Put the shell script into one of the following directories: /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ From now, your script will be executed - the crond service automatically executes any scripts present in /etc/cron.hourly , /etc/cron.daily , /etc/cron.weekly , and /etc/cron.monthly directories at their corresponding times. 24.2. Scheduling a Recurring Asynchronous Job Using Anacron Anacron , like cron , is a service that enables you to schedule running a task, often called a job, at regular times. However, anacron differs from cron in two ways: If the system is not running at the scheduled time, an anacron job is postponed until the system is running; An anacron job can run once per day at most. Users specify anacron jobs in anacron table files, also called anacrontab files. These files are then read by the crond service, which executes the jobs. 24.2.1. Prerequisites for Anacrob Jobs Before scheduling an anacron job: Verify that you have the cronie-anacron package installed: The cronie-anacron is likely to be installed already, because it is a sub-package of the cronie package. If it is not installed, use this command: The crond service is enabled - made to start automatically at boot time - upon installation. If you disabled the service, enable it: Start the crond service for the current session: (optional) Configure anacron . For example, you can change: shell to be used when executing jobs the PATH environment variable mail addressee if a job sends emails. See the anacrontab (5) manual page for information on configuring anacron . Important By default, the anacron configuration includes a condition that prevents it from running if the computer is not plugged in. This setting ensures that the battery is not drained by running anacron jobs. If you want to allow anacron to run even if the computer runs on battery power, open the /etc/cron.hourly/0anacron file and comment out the following part: 24.2.2. Scheduling an Anacron Job Scheduling an anacron Job as root User The root user uses the anacron table in /etc/anacrontab . Use the following procedure to schedule a job as root . Scheduling an anacron Job as root User Choose: Frequency of executing the job. For example, use 1 to specify every day or 3 to specify once in 3 days. The delay of executing the job. For example, use 0 to specify no delay or 60 to specify 1 hour of delay. The job identifier, which will be used for logging. For example, use my.anacron.job to log the job with the my.anacron.job string. The command to execute. For example, use /usr/local/bin/my-script.sh Combine the chosen values into the job specification. Here is an example specification: Add the resulting line to /etc/anacrontab . The job will now run as scheduled. For simple job examples, see the /etc/anacrontab file. For full reference on how to specify a job, see the anacrontab (5) manual page. Scheduling Hourly, Daily, Weekly, and Monthly Jobs You can schedule daily, weekly, and monthly jobs with anacron . See the section called "Scheduling Hourly, Daily, Weekly, and Monthly Jobs" . 24.3. Scheduling a Job to Run at a Specific Time Using at To schedule a one-time task, also called a job, to run once at a specific time, use the at utility. Users specify at jobs using the at utility. The jobs are then executed by the atd service. 24.3.1. Prerequisites for At Jobs Before scheduling an at job: Install the at package: The atd service is enabled - made to start automatically at boot time - upon installation. If you disabled the service, enable it: Start the atd service for the current session: 24.3.2. Scheduling an At Job A job is always run by some user. Log in as the desired user and run: Replace time with the time specification. For details on specifying time, see the at (1) manual page and the /usr/share/doc/at/timespec file. Example 24.1. Specifying Time for At To execute the job at 15:00, run: If the specified time has passed, the job is executed at the same time the day. To execute the job on August 20 2017, run: or To execute the job 5 days from now, run: At the displayed at> prompt, enter the command to execute and press Enter: Repeat this step for every command you want to execute. Note The at> prompt shows which shell it will use: The at utility uses the shell set in user's SHELL environment variable, or the user's login shell, or /bin/sh , whichever is found first. Press Ctrl+D on an empty line to finish specifying the job. Note If the set of commands or the script tries to display information to standard output, the output is emailed to the user. Viewing Pending Jobs To view the list of pending jobs, use the atq command: Each job is listed on a separate line in the following format: The job_queue column specifies whether a job is an at or a batch job. a stands for at , b stands for batch . Non-root users only see their own jobs. The root user sees jobs for all users. Deleting a Scheduled Job To delete a scheduled job: List pending jobs with the atq command: Find the job you want to delete by its scheduled time and the user. Run the atrm command, specifying the job by its number: 24.3.2.1. Controlling Access to At and Batch You can restrict access to the at and batch commands for specific users. To do this, put user names into /etc/at.allow or /etc/at.deny according to these rules: Both access control files use the same format: one user name on each line. No white space is permitted in either file. If the at.allow file exists, only users listed in the file are allowed to use at or batch , and the at.deny file is ignored. If at.allow does not exist, users listed in at.deny are not allowed to use at or batch . The root user is not affected by the access control files and can always execute the at and batch commands. The at daemon ( atd ) does not have to be restarted if the access control files are modified. The access control files are read each time a user tries to execute the at or batch commands. 24.4. Scheduling a Job to Run on System Load Drop Using batch To schedule a one-time task, also called a job, to run when the system load average drops below the specified value, use the batch utility. This can be useful for performing resource-demanding tasks or for preventing the system from being idle. Users specify batch jobs using the batch utility. The jobs are then executed by the atd service. 24.4.1. Prerequisites for Batch Jobs The batch utility is provided in the at package, and batch jobs are managed by the atd service. Hence, the prerequisites for batch jobs are the same as for at jobs. See Section 24.3.1, "Prerequisites for At Jobs" . 24.4.2. Scheduling a Batch Job A job is always run by some user. Log in as the desired user and run: At the displayed at> prompt, enter the command to execute and press Enter: Repeat this step for every command you want to execute. Note The at> prompt shows which shell it will use: The batch utility uses the shell set in user's SHELL environment variable, or the user's login shell, or /bin/sh , whichever is found first. Press Ctrl+D on an empty line to finish specifying the job. Note If the set of commands or the script tries to display information to standard output, the output is emailed to the user. Changing the Default System Load Average Limit By default, batch jobs start when system load average drops below 0.8. This setting is kept in the atq service. To change the system load limit: To the /etc/sysconfig/atd file, add this line: Substitute x with the new load average. For example: Restart the atq service: Viewing Pending Jobs To view the list of pending jobs, use the atq command. See the section called "Viewing Pending Jobs" . Deleting a Scheduled Job To delete a scheduled job, use the atrm command. See the section called "Deleting a Scheduled Job" . Controlling Access to Batch You can also restrict the usage of the batch utility. This is done for the batch and at utilities together. See Section 24.3.2.1, "Controlling Access to At and Batch" . 24.5. Scheduling a Job to Run on Boot Using a systemd Unit File The cron , anacron , at , and batch utilities allow scheduling jobs for specific times or for when system workload reaches a certain level. It is also possible to create a job that will run during the system boot. This is done by creating a systemd unit file that specifies the script to run and its dependencies. To configure a script to run on the boot: Create the systemd unit file that specifies at which stage of the boot process to run the script. This example shows a unit file with a reasonable set of Wants= and After= dependencies: If you use this example: substitute /usr/local/bin/foobar.sh with the name of your script modify the set of After= entries if necessary For information on specifying the stage of boot, see Section 10.6, "Creating and Modifying systemd Unit Files" . If you want the systemd service to stay active after executing the script, add the RemainAfterExit=yes line to the [Service] section: Reload the systemd daemon: Enable the systemd service: Create the script to execute: If you want the script to run during the boot only, and not on every boot, add a line that disables the systemd unit: Make the script executable: 24.6. Additional Resources For more information on automating system tasks on Red Hat Enterprise Linux, see the resources listed below. Installed Documentation cron - The manual page for the crond daemon documents how crond works and how to change its behavior. crontab - The manual page for the crontab utility provides a complete list of supported options. crontab (5) - This section of the manual page for the crontab utility documents the format of crontab files.
~]# yum install cronie ~]# systemctl enable crond.service ~]# systemctl start crond.service 0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * root /usr/local/bin/my-script.sh SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root For details see man 4 crontabs Example of job definition: .---------------- minute (0 - 59) | .------------- hour (0 - 23) | | .---------- day of month (1 - 31) | | | .------- month (1 - 12) OR jan,feb,mar,apr | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat | | | | | * * * * * user-name command to be executed [bob@localhost ~]USD crontab -e 0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * bob /home/bob/bin/script.sh 0,10,20,30,40,50 17-20 15 Jun,Jul,Aug * /home/bob/bin/script.sh [bob@localhost ~]USD crontab -l @daily /home/bob/bin/script.sh ~]# rpm -q cronie-anacron ~]# yum install cronie-anacron ~]# systemctl enable crond.service ~]# systemctl start crond.service Do not run jobs when on battery power online=1 for psupply in AC ADP0 ; do sysfile="/sys/class/power_supply/USDpsupply/online" if [ -f USDsysfile ] ; then if [ `cat USDsysfile 2>/dev/null`x = 1x ]; then online=1 break else online=0 fi fi done 3 60 cron.daily /usr/local/bin/my-script.sh ~]# yum install at ~]# systemctl enable atd.service ~]# systemctl start atd.service ~]# at time ~]# at 15:00 ~]# at August 20 2017 ~]# at 082017 ~]# now + 5 days ~]# at 15:00 at> sh /usr/local/bin/my-script.sh at> warning: commands will be executed using /bin/sh ~]# atq 26 Thu Feb 23 15:00:00 2017 a root 28 Thu Feb 24 17:30:00 2017 a root job_number scheduled_date scheduled_hour job_class user_name ~]# atq 26 Thu Feb 23 15:00:00 2017 a root 28 Thu Feb 24 17:30:00 2017 a root ~]# atrm 26 ~]# batch ~]# batch at> sh /usr/local/bin/my-script.sh warning: commands will be executed using /bin/sh OPTS='-l x ' OPTS='-l 0.5' systemctl restart atq ~]# cat /etc/systemd/system/one-time.service The script needs to execute after: network interfaces are configured Wants=network-online.target After=network-online.target all remote filesystems (NFS/_netdev) are mounted After=remote-fs.target name (DNS) and user resolution from remote databases (AD/LDAP) are available After=nss-user-lookup.target nss-lookup.target the system clock has synchronized After=time-sync.target [Service] Type=oneshot ExecStart=/usr/local/bin/foobar.sh [Install] WantedBy=multi-user.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/local/bin/foobar.sh ~]# systemctl daemon-reload ~]# systemctl enable one-time.service ~]# cat /usr/local/bin/foobar.sh #!/bin/bash touch /root/test_file #!/bin/bash touch /root/test_file systemctl disable one-time.service ~]# chmod +x /usr/local/bin/foobar.sh