cron Daemon IV: Scheduling Processes

cron Daemon IV: Scheduling Processes 

Scheduling Processes 

Using cron to Manage Scheduled User Jobs


Users on your system can create their own schedules using a crontab file that is associated with
their user account.



Unlike system crontab files, which are saved in /etc, user crontab files are 
stored in

/var/spool/cron/tabs



If a user has created a crontab file, it will be saved under his or her username in this directory.


Before proceeding, I should point out that not all Linux system administrators want to allow 
their users to do this. If allowing users to make their own crontab files and run programs on a
schedule makes you nervous, you can lock the system to prevent them from doing so. To do this,
you use an approach similar to that used when working with the at daemon.


The cron daemon will read the 


/etc/cron.allow 


and


/etc/cron.deny 


files when it starts up to determine who can and who can’t create crontab schedules.


By default, only the

/etc/cron.deny 


file is created automatically, and it contains only one restriction by default for the guest user
account.


All other users are allowed to create crontab files to schedule jobs. 

If you create an 


/etc/cron.allow 


file, then only the users in that file will be allowed to create crontab files; all others will
be denied.



With that out of the way, let’s discuss how users can create their own crontab files. To do this,
they can use the


crontab –e 


command. After this command has been entered, the vi editor is opened with a new, blank crontab file loaded.



In this file, the user simply adds lines for each job they want to run using the syntax we
reviewed previously. For example, in Figure 13-13, the tar command is run at 5:10 p.m. every day
to back up the user’s home directory to a file named ~/homebak.tar.



The file is edited using standard vi commands and keystrokes, which you learned earlier in
this book. (I told you knowing how to use vi would come in handy!) When you’re done, exit vi
and save the file. After doing so, a new crontab file for the user is created in


/var/spool/cron/tabs


as shown in the next example.



In addition, the cron service is reloaded so the new configuration can be applied.



openSUSE:/ # ls /var/spool/cron/tabs/
rtracy
openSUSE:/ # cat /var/spool/cron/tabs/rtracy
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.wwzr9t installed on Tue Dec 2 22:31:44 2014)
# (Cronie version 4.2)
10 17 * * * /bin/tar -cvf ~/homebak.tar ~



In this example, I used the cat command to view the tux user’s crontab file. However, you can
also use the


crontab –l 


command to display your user’s crontab file.


In addition, you can use the


crontab –r 


command to remove your user’s crontab file






LX0-104 Exam Objectives (L)

cron Daemon III: Scheduling Processes

cron Daemon III: Scheduling Processes 


Scheduling Processes 

Using cron to Manage Scheduled System Jobs 

Using cron to run scheduled system jobs is an extremely useful tool for a Linux system administrator. You can configure your systems to perform a wide variety of tasks on a regular schedule automatically, thus saving you a ton of time and effort.


Remember when I mentioned the problems with running regular backups? Creating a system
job in cron that runs a backup on a regular schedule saves me tons of time. If I don’t have time to
visit a client site on a particular day, I don’t have to worry. I know that cron will run a backup at
the preconfigured time. All I have to do is drop by now and then to verify that everything is still
working properly and to perhaps rotate the backup media. I love cron!



To run system jobs, the cron service uses the 


/etc/crontab 

file, shown next, to configure what jobs to run:



openSUSE:/etc # cat ./crontab
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * * root test -x /usr/lib/cron/run-crons &&
/usr/lib/cron/run-crons >/dev/null 2>&1




As you can see in this example, the

/etc/crontab 

file contains commands that are used to run scripts found in four different directories:



• /etc/cron.hourly 
  Contains cron scripts that are run every hour 

• /etc/cron.daily 
  Contains cron scripts that are run every day

• /etc/cron.weekly 
  Contains cron scripts that are run once a week 

• /etc/cron.monthly 
  Contains cron scripts that are run once a month



All scripts found in any of these directories are automatically run by cron according to the
specified schedule. For example, the /etc/cron.daily directory contains a variety of scripts that are used to clean up your system and rotate your logs once each day. These scripts are shown here:


openSUSE:/etc/cron.daily # ls
logrotate suse-clean_catman suse.de-backup-rpmdb
mdadm suse-do_mandb suse.de-check-battery
packagekit-background.cron suse.de-backup-rc.config suse.de-cron-local



If you have a system task that needs to be run on one of these four schedules, you can simply 
create a script file and copy it into the appropriate cron directory in /etc. 
What do you do, however, if your system job needs to run on a schedule other than one of the
four used by the cron directories? No problem. The cron daemon has got you covered.



In addition to the four directories just presented, there’s a fifth directory in 

/etc/ called cron.d. 


If you need a system job to run on a custom schedule, you can create a crontab file in this
directory where it will be read and run by the cron daemon.



How do you create a crontab file? It looks difficult but it really isn’t. A crontab file is simply a text 
file that uses one line per job.

Each line has six fields, separated by tabs, as detailed in Table 13-3.



Many times, you will see an asterisk (*) in one or more fields in a given crontab file. This wildcard means “match everything.”


For example, suppose I wanted to run the tar command to back up the /home directory using
the


tar –cvf /media/usb/backup.tar /home


command every day of every month, except Sundays, at 11:05 p.m.



I could create a crontab file in /etc/crontab.d and add the following line: 


5 23 * * 1-6 /bin/tar -cvf /media/usb/backup.tar /home 

This line in the crontab file specifies that the command be run at 5 minutes after 11:00 p.m. 
(23) every day (*) of every month (*) on Monday (1) through Saturday (6). 



System cron jobs run as the root user!



[Table 13-3: The crontab File Fields, p 488]







LX0-104 Exam Objectives (L)

cron Daemon II: Scheduling Processes

cron Daemon II: Scheduling Processes 


Scheduling Processes 

How cron Works 

The cron daemon is a service that runs continuously in the background on your system and 
checks a special file called a 

crontab 

file once every minute to see if there’s a scheduled job it should run. If your distribution uses init,
then the cron daemon is managed using the cron init script in your init directory.

If your distribution uses systemd, you use the

systemctl 

command to manage the cron daemon.


By default, the cron daemon is configured to run automatically every time the system boots
on most Linux distributions. If not, you’ll need to start it manually using the cron init script in
your system’s init directory.



You can configure cron to run system jobs or user-specific jobs







LX0-104 Exam Objectives (L)

cron Daemon I: Scheduling Processes

cron Daemon I: Scheduling Processes 


Scheduling Processes 

Using the cron Daemon 

The at daemon is great; however, it has one key drawback. It can only schedule a job to run once
in the future. That’s not a problem if you only want the job to run once. However, there will be
many times when you want a job to run in the future on a regular schedule. For example, you may
need to run a process, such as a backup utility, every day at a certain time. In this situation, the at
daemon doesn’t cut it. You need a tool that can handle repetitious schedules.



The cron daemon can do just that. Unlike at, cron can run commands on a schedule you
specify. It’s a very powerful, very useful service. I use at occasionally. However, cron is a service
hat I use all of the time. In fact, I would have a hard time getting my work done without it.
Most of my clients’ offices are many miles from my office. Making rounds just to run backups
for all of my clients each day would take up all my time. Of course, I don’t dare trust my clients’
administrative personnel to make sure backups occur each day. Instead, I set up the cron daemon
to run the backups for me. That way, I know that backups are occurring on a regular schedule
and that the correct command has been issued to create them.
In this part of the chapter, we’ll discuss the following:



• How cron works
• Using cron to manage scheduled system jobs
• Using cron to manage scheduled user jobs







LX0-104 Exam Objectives (L)

Scheduling Processes

Scheduling Processes 


So far in this chapter, you’ve learned how to execute and manage processes on a Linux system
from the shell prompt. However, there will be many occasions when you need a process to run
automatically without any intervention on your part. Backups are a good example. One of the
key problems with backups is not that system administrators perform them incorrectly; it’s that
they forget to perform them at all! One of the worst things you can do in your backup strategy is
to rely on a human being to remember to run them.


Instead, you can configure your Linux system to run programs for you automatically. This
removes the human element from the equation and ensures that the specified programs execute
regularly and on time. Two key utilities can be used to schedule processes to run in the future.
We’ll discuss the following in this part of the chapter:




• Using the at daemon
• Using the cron daemon
• Using anacron








LX0-104 Exam Objectives (L)