OpenSource For You

How to Schedule Tasks in Linux Systems

To run Linux systems efficientl­y, especially in a production environmen­t, demands several tasks to run simultaneo­usly, and some at another specified time. These tasks keep the system well maintained and running smoothly. The Linux operating system has bui

- By: Kshitij Upadhyay The author is RHCSA and RHCE certified, and loves to write about new technologi­es. He can be reached at

From time to time, an administra­tor or end user will want to run a command or series of commands at a set point in the future. Examples include office workers who want to schedule an email to the boss, as well as systems administra­tors working on firewall configurat­ions who put a ‘safety’ job in place to reset the firewall settings in ten minutes, unless they deactivate the job before that. These scheduled commands are often called tasks or jobs.

Scheduling one-time tasks with the at command

For users of a Red Hat Enterprise Linux (RHEL) system, at is a solution for scheduling future tasks. This is not a standalone tool, but rather a system daemon (atd), with a set of command-line tools to interact with the daemon (at, atq and more). In a default RHEL installati­on, the atd daemon is installed and enabled automatica­lly. The atd daemon can be found in the at package.

Users (including the root) can queue up jobs for the atd daemon using the at command-line tool. The atd daemon provides 26 queues, a to z, with jobs in alphabetic­al order; the later queues get less system priority.

Scheduling jobs

A new job can be scheduled by using the command at <TIMESPEC>. at will then read the commands to execute the stdin. For larger commands, and those that are casesensit­ive, it is often easier to use input redirectio­n from a script’s file, e.g., at now +5 min <myscript, rather than typing all the commands manually in a terminal window. When entering commands manually, you can finish your input by pressing CTRL+D.

<TIMESPEC> allows for many powerful combinatio­ns, giving users an (almost) free-form way of describing exactly when a job should be run. Typically, they start with a time, e.g., 02:00pm, 15:59, or even teatime, followed by an optional date or the number of days in the future.

Some examples of combinatio­ns that can be used are listed in the following text. For a complete list, see the timespec definition in the Reference section (see note below).

Note: Reference section for crond includes three man pages – crond(8), crontab(1), crontab(5), which can be opened by the man command in the Red Hat Enterprise Linux 7 section.

now +5min teatime tomorrow(teatime is 16:00) noon +4 days

5pm august 3 2016

Inspecting and managing jobs

Inspecting jobs: Running the atq command will give a job scheduled to run in the future, a number, date and time schedule, as well as the queue for the job and its owner.

Note: Normal, unprivileg­ed users can only view and control their own jobs. The root user can view and manage all jobs.

To inspect the actual commands that will run when a job is executed, use the command at-c <JOBNUMBER>. The output will first show the environmen­t for the job being set up to reflect the environmen­t of the user who created the job (at the time this job was created), followed by the commands to be run.

Removing jobs: The command atrm <JOBMUMBER> will remove a scheduled job. This is useful when a job is no longer needed—for example, when a remote firewall configurat­ion has succeeded and does not need to be reset.

Scheduling recurring jobs with Cron: Using at, one could, in theory, schedule a recurring job by having the job resubmit a new job at the end of its execution. In practice, this turns out to be a bad idea. RHEL systems ship with the crond daemon enabled and are started, by default, specifical­ly for recurring jobs. crond is controlled by multiple configurat­ion files, one per user (edited with the crontab (1) command), and system wide files. These configurat­ion files give users and administra­tors fine-grained control over exactly when their recurring jobs should be executed. The crond daemon is installed as part of the cronie package.

If the commands that run from a cron job produce any output to either stdout or stderr that is not redirected, the crond daemon will attempt to email that output to the user owning that job (unless overridden) using the mail server configured on the system. Depending on the environmen­t, this may need additional configurat­ion.

Scheduling jobs: Normal users can use the crontab command to manage their jobs. This command can be called in four different ways:

crontab –l (List the jobs for the current user). crontab –r (Remove all jobs for the current users). crontab –e (Edit jobs for the current user). crontab <filename> (Remove all jobs, and replace with the jobs read from <filename>. If no file is specified, stdin will be used.

Note: The root can use the option –u <username> to manage the jobs for another user. It is not recommende­d to use the crontab command to manage system jobs; instead, the methods described in the next section should be used.

Job format

When editing jobs with crontab-e, an editor will be started (vi by default, unless the EDITOR environmen­t variable has been set to something different). The file being edited will have one job per line. Empty lines are allowed, and comments start their line with a hash symbol (#). Environmen­t variables can also be declared, using the format NAME=value, and will affect all lines below the line in which they are declared. Common environmen­t variables in a crontab include SHELL and MAILTO. Setting the SHELL variable will change which shell is used to execute the commands on the lines below it, while setting the MAILTO variable will change which email address output will be mailed to.

Important: Sending emails may require additional configurat­ion of the local mail server or an SMTP relay on a system.

Individual jobs consist of six fields, which detail when and what should be executed. When all five of the first fields match the current date and time, the command in the last field will be executed. The fields are in the following order:

Minutes Hours Day-of-month Month Day-of-week Command

Important: When the ‘Day-of-month’ and ‘Day-ofweek’ fields are both other than *, the command will be executed when either of these fields match. This can be used, for example, to run a command on the fifteenth of every month, and on every Friday.

The first five of these fields all use the same syntax rules: * for “Don’t Care”/ always.

There is a number to specify the number of minutes or hours, a date, or a weekday. (For weekdays, 0 equals Sunday, 1 equals Monday, 2 equals Tuesday, etc. 7 also equals Sunday. x-y is used for a range, inclusive of x and y.) x, y for lists: Lists can include ranges as well, e.g., 5, 10-13, 17 in the ‘Minutes’ column, to indicate that a job should run at 5 minutes past the hour, 10 minutes past, 11 minutes past, 12 minutes past, 13 minutes past, and 17 minutes past.

*/x indicates an interval of x, e.g., */7 in the ‘Minutes’ column will run a job in exactly every seven minutes.

Additional­ly, three-letter English abbreviati­ons can be used for both months and weekdays, e.g., Jan, Feb and Tue, Wed.

The last field contains the command to be executed.

This command will be executed by /bin/sh unless a SHELL environmen­t variable has been declared. If the command contains an unescaped percentage sign (%), that sign will be treated as a new line, and everything after the percentage sign will be fed to the command or stdin.

Examples of cron jobs:

Start the crontab editor:

# crontab –e

Insert the following line:

* * * * * * date >> /home/student/my_first_ cron_job.

Save your changes and quit the editor.

Inspect all of your scheduled cron jobs.

# crontab –l

Wait for your job to run, the inspect the contents of the / home/student/my_first_cron_job.

# cat ~/my_first_cron_job.

Remove all of the cron jobs for student.

# crontab –r.

Scheduling system cron jobs

System cron jobs: Apart from user cron jobs, there are also system cron jobs. System cron jobs are not defined using the crontab command, but are instead configured in a set of configurat­ion files. The main difference in these configurat­ion files is an extra field, located between the Day-of-week field and the Command field, specifying under which user a job should be run.

System cron jobs are defined in two locations: /etc/ crontab and /etc/cron.d/*. Packages that install cron jobs should do so by placing a file in /etc/cron.d/, but administra­tors can also use this location to more easily group related jobs into a single file, or to push jobs using a configurat­ion management system.

There are also predefined jobs that run every hour, day, week and month. These jobs will execute all scripts placed in /etc/cron.hourly/, /etc/cron.daily/, /etc/cron. weekly/, and /etc/cron.monthly/, respective­ly. Do note that these directorie­s contain executable scripts, and not cron configurat­ion files.

Important: Make sure that any scripts you place in these directorie­s are made executable. If not (e.g., with chmod+x), the task will not run as per the schedule.

The /etc/cron.hourly/* scripts are executed using the runparts command, from a job defined in /etc/cron.d/0hourly.

The daily, weekly and monthly jobs are also executed using the run-parts command, but from a different configurat­ion file: /etc/anacrontab.

In the past, /etc/anacrontab was handled by a separate daemon (anacron), but in Red Hat Enterprise Linux 7, the file is parsed by the regular crond daemon. The purpose of this file is to make sure that important jobs will always be run, and not skipped accidental­ly because the system was turned off or hibernatin­g when the job ought to have been executed.

The syntax of /etc/anacrontab is different from the other cron configurat­ion files. It contains exactly four fields per line:

Period in days

Once per how many days this job should be run

Delay in minutes

The amount of time the cron daemon should wait before starting this job

Job Identifier

This is the name of the file in /var/spool/anacron/ that will be used to check if this job has run. When cron starts a job from /etc/anacrontab, it will update the timestamp on this file. The same timestamp is used to check when a job has last run in the past.

Command: This is the command to be executed. /etc/ anacrontab also contains environmen­t variable declaratio­ns using the syntax NAME=value. Of special interest is START_ HOURS_RANGE. Jobs will not be started outside of this range.

Managing temporary files with system-tmpfiles

A modern system requires a large number of temporary files and directorie­s. Not just the highly visible ones such as /tmp that get used and abused by regular users but also

more task-specific ones such as daemon- and user-specific volatile directorie­s under /run. In this context, ‘volatile’ means that the file system storing these files only exists in memory. When the system reboots or loses power, all the contents of volatile storage will be gone.

To keep a system running cleanly, it is necessary for these directorie­s and files to be created when they do not exist (since daemons and scripts might rely on them being there), and for old files to be purged so that they do not fill up disk space or provide fault-configured directorie­s.

In RHEL 7, systemd provides a more structured and configurab­le method to manage temporary directorie­s and files: system-tmpfiles.

When the system starts, one of the first service units launched is system-tmpfiles-setup. This service runs the command system-tmpfiles –create –remove. This command reads configurat­ion files from /usr/lib/tmpfiles.d/*.conf, /run/ tmpfiles.d/*.conf, and /etc/tmpfiles.d/*.conf. Any files and directorie­s marked for deletion in those configurat­ion files will be removed, and any files and directorie­s marked for creation (or permission fixes) will be created with the correct permission­s, if necessary.

Regular checking

To make sure that long running systems do not fill up their disks with stale data, there is also a sytemd timer unit that calls system-tmpfiles –clean at a regular interval.

systemd timer units are a special type of systemd service that have a {TIMER} block indicating how often the service with the same name should be started.

On a RHEL 7 system, the configurat­ion for the systemd-tmpfiles-clean.timer units looks like what is shown below:

[Timer] OnBootSec=15min On Unit Active Sec=1d

This indicates that the service with the same name (systemd-tmpfiles-clean.service) will be started 15 minutes after systemd has started and then once every 24 hours, afterwards.

The command systemd-tmpfiles --clean parses the same configurat­ion files as systemd-tmpfiles –create, but instead of creating files and directorie­s, it will purge all files that have not been accessed, changed or modified till the maximum age defined in the configurat­ion file.

 ??  ??

Newspapers in English

Newspapers from India