Scheduling Processes Partial list of terms
•/etc/cron .{d,daily,hourly,monthly,weekly}
•/etc/at .deny
•/etc/at .allow
•/etc/crontab
•/etc/cron .allow
•/etc/cron .deny
•/var/spool/cron/*
•crontab
•at
•atq
•atrm
•anacron
•/etc/anacrontab
LX0-104 Exam Objectives (L)
Showing posts with label scheduling processes. Show all posts
Showing posts with label scheduling processes. Show all posts
Friday, December 9, 2016
cron Daemon IV: Scheduling Processes
cron Daemon IV: Scheduling Processes
Scheduling Processes
Using anacron
Some distributions use anacron along with cron to automate the running of tasks. The two services working pretty much the same manner. The key difference is that cron assumes that your computer system will remain up and running 24 hours a day, 7 days a week. That’s fine for some systems, such as servers anddesktops, but not for others. For example, a notebook system is very likely to be off or asleep during certain periods of the day. If a system is not powered on when a scheduled cron job should run, it is skipped.
The anacron service attempts to work around this issue. If a job is scheduled in anacron, but
the system is off, then the missed job will automatically run when the system comes back up.
Just as cron uses the /etc/crontab file,
anacron uses the
/etc/anacrontab
file. This file uses the following fields:
period delay job-identifier command
The first field specifies the recurrence period (in days). For example, you could use any one of
the following values in this field:
• 1
The task recurs daily.
• 7
The task recurs weekly.
• 30
The task recurs monthly.
The second field specifies the delay (in minutes) anacron should wait before executing a
skipped job after the system starts up.
The third field contains the job identifier. This is the name that will be used for the job’s timestamp file and must be unique for each anacron job. This file is created in the
/var/spool/anacron
directory and contains a single line with a timestamp that indicates the last time the particular job
was run.
The fourth field specifies the command or script that should be run.
Consider the following example in which anacron is configured to run the /usr/bin/updatedb.sh
script once a day. If the system is down when the anacron job is supposed to run, the script will
be executed 30 minutes after the system comes back up.
openSUSE:/ # cat /etc/anacrontab
1 30 updatedbtime.log /usr/bin/updatedb.sh
Notice that this file does not specify the exact time when the job will run. This is configured
by the START_HOURS_RANGE variable in the /etc/anacrontab file. In the following example,
the start range is set to 3-22, which specifies a time range from 3 a.m.to 10 p.m.
openSUSE# cat /etc/anacrontab
...
START_HOURS_RANGE=3-22
It’s important to note that anacron also adds a random number of minutes to whatever value
you specified in the second field of the anacrontab file. The number of minutes that can be added is constrained by the RANDOM_DELAY variable within the /etc/anacrontab file. By default,this variable is set to a value of 45, which causes anacron to add a random number of minutes between 0 and 45 to the delay time in the anacrontab file. This is shown here:
openSUSE# cat /etc/anacrontab
...
RANDOM_DELAY=45
LX0-104 Exam Objectives (L)
Scheduling Processes
Using anacron
Some distributions use anacron along with cron to automate the running of tasks. The two services working pretty much the same manner. The key difference is that cron assumes that your computer system will remain up and running 24 hours a day, 7 days a week. That’s fine for some systems, such as servers anddesktops, but not for others. For example, a notebook system is very likely to be off or asleep during certain periods of the day. If a system is not powered on when a scheduled cron job should run, it is skipped.
The anacron service attempts to work around this issue. If a job is scheduled in anacron, but
the system is off, then the missed job will automatically run when the system comes back up.
Just as cron uses the /etc/crontab file,
anacron uses the
/etc/anacrontab
file. This file uses the following fields:
period delay job-identifier command
The first field specifies the recurrence period (in days). For example, you could use any one of
the following values in this field:
• 1
The task recurs daily.
• 7
The task recurs weekly.
• 30
The task recurs monthly.
The second field specifies the delay (in minutes) anacron should wait before executing a
skipped job after the system starts up.
The third field contains the job identifier. This is the name that will be used for the job’s timestamp file and must be unique for each anacron job. This file is created in the
/var/spool/anacron
directory and contains a single line with a timestamp that indicates the last time the particular job
was run.
The fourth field specifies the command or script that should be run.
Consider the following example in which anacron is configured to run the /usr/bin/updatedb.sh
script once a day. If the system is down when the anacron job is supposed to run, the script will
be executed 30 minutes after the system comes back up.
openSUSE:/ # cat /etc/anacrontab
1 30 updatedbtime.log /usr/bin/updatedb.sh
Notice that this file does not specify the exact time when the job will run. This is configured
by the START_HOURS_RANGE variable in the /etc/anacrontab file. In the following example,
the start range is set to 3-22, which specifies a time range from 3 a.m.to 10 p.m.
openSUSE# cat /etc/anacrontab
...
START_HOURS_RANGE=3-22
It’s important to note that anacron also adds a random number of minutes to whatever value
you specified in the second field of the anacrontab file. The number of minutes that can be added is constrained by the RANDOM_DELAY variable within the /etc/anacrontab file. By default,this variable is set to a value of 45, which causes anacron to add a random number of minutes between 0 and 45 to the delay time in the anacrontab file. This is shown here:
openSUSE# cat /etc/anacrontab
...
RANDOM_DELAY=45
LX0-104 Exam Objectives (L)
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)
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)
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)
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
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)
at: Scheduling Processes
at: Scheduling Processes
Scheduling Processes
Using the at Daemon
Using at is a great way to schedule a process to run once sometime in the future. The at service is a system daemon (called atd) that runs in the background on your system.
Most Linux distributions install this service for you during the initial installation of the system. If not, you may need to install it manually from your installation repository using the rpm utility.
If your distribution uses init, then the startup script used to start the atd daemon is located in your init script directory, which should be either /etc/init.d or /etc/rc.d/init.d, depending on your particular distribution. The name of the script is atd.
Before attempting to use at, you need to make sure the atd daemon is running. You can do
this by entering
rcatd start
at the shell prompt. You can also run the script file with its full path followed by start at the shell prompt to accomplish the same task. Make sure the atd daemon will start automatically on boot using the
insserv or chkconfig
command.
If your distribution uses systemd instead of init, you start the atd daemon by entering
systemctl start atd
at the shell prompt as root.
At this point, you need to specify which users can and which users cannot create at jobs. This can be done by editing the following files:
• /etc/at.allow
Users listed in this file are allowed to create at jobs.
• /etc/at.deny
Users listed in this file are not allowed to create at jobs.
To use at to schedule a command to run at a future time, complete the following:
1.At the shell prompt enter
at time
The at daemon is very flexible as to how you specify the time value in this command.
[Observe the syntax shown in Table 13-2, p485 ]
After you enter the at command and a time value from Table 13-2, the at> prompt is displayed,
as shown here:
openSUSE:~ # at now +10 minutes
warning: commands will be executed using /bin/sh
at>
2.At the at> prompt, enter the command(s) you want at to run for you. It’s important to
note that if your commands display output on the screen from the shell prompt, you
won’t see the output when the commands are run by at. You have two different options
for viewing the output. First of all, if you don’t specify any alternative, at will e-mail the
output to your local user account.
Alternatively, you can also redirect the output to a file. You learned how to do this earlier
in this book. For example, if you wanted to run the tail /var/log messages command in the
future with at, you could enter
tail /var/log/messages > ~/atoutput.txt
at the at> prompt to send the output from the command to a text file named atoutput.txt in your home directory.
3.Press enter if you want to add additional commands. You can run multiple commands within the same job. Each command should be on its own line.
4. When you’re done entering commands, press
ctrl-d
When you do, the at> prompt will disappear, the job will be scheduled, and a job number will be assigned, as shown here:
openSUSE:~ # at now +10 minutes
warning: commands will be executed using /bin/sh
at> tail /var/log/messages > ~/atoutput.txt
at> <EOT>
job 3 at 2011-04-02 08:57
openSUSE:~ #
Once you’ve configured the job, you can use the
atq
command to view a list of pending at jobs.
This is shown next:
openSUSE:~ # atq
3 2011-04-02 08:57 a root
If you are logged in as a regular user, the atq command will display only the jobs associated
with the current user account.
If you’re logged in as root, then atq will display all pending jobs for all users.
If you need to remove a pending job from the list, you can use the
atrm job_number
LX0-104 Exam Objectives (L)
Scheduling Processes
Using the at Daemon
Using at is a great way to schedule a process to run once sometime in the future. The at service is a system daemon (called atd) that runs in the background on your system.
Most Linux distributions install this service for you during the initial installation of the system. If not, you may need to install it manually from your installation repository using the rpm utility.
If your distribution uses init, then the startup script used to start the atd daemon is located in your init script directory, which should be either /etc/init.d or /etc/rc.d/init.d, depending on your particular distribution. The name of the script is atd.
Before attempting to use at, you need to make sure the atd daemon is running. You can do
this by entering
rcatd start
at the shell prompt. You can also run the script file with its full path followed by start at the shell prompt to accomplish the same task. Make sure the atd daemon will start automatically on boot using the
insserv or chkconfig
command.
If your distribution uses systemd instead of init, you start the atd daemon by entering
systemctl start atd
at the shell prompt as root.
At this point, you need to specify which users can and which users cannot create at jobs. This can be done by editing the following files:
• /etc/at.allow
Users listed in this file are allowed to create at jobs.
• /etc/at.deny
Users listed in this file are not allowed to create at jobs.
To use at to schedule a command to run at a future time, complete the following:
1.At the shell prompt enter
at time
The at daemon is very flexible as to how you specify the time value in this command.
[Observe the syntax shown in Table 13-2, p485 ]
After you enter the at command and a time value from Table 13-2, the at> prompt is displayed,
as shown here:
openSUSE:~ # at now +10 minutes
warning: commands will be executed using /bin/sh
at>
2.At the at> prompt, enter the command(s) you want at to run for you. It’s important to
note that if your commands display output on the screen from the shell prompt, you
won’t see the output when the commands are run by at. You have two different options
for viewing the output. First of all, if you don’t specify any alternative, at will e-mail the
output to your local user account.
Alternatively, you can also redirect the output to a file. You learned how to do this earlier
in this book. For example, if you wanted to run the tail /var/log messages command in the
future with at, you could enter
tail /var/log/messages > ~/atoutput.txt
at the at> prompt to send the output from the command to a text file named atoutput.txt in your home directory.
3.Press enter if you want to add additional commands. You can run multiple commands within the same job. Each command should be on its own line.
4. When you’re done entering commands, press
ctrl-d
When you do, the at> prompt will disappear, the job will be scheduled, and a job number will be assigned, as shown here:
openSUSE:~ # at now +10 minutes
warning: commands will be executed using /bin/sh
at> tail /var/log/messages > ~/atoutput.txt
at> <EOT>
job 3 at 2011-04-02 08:57
openSUSE:~ #
Once you’ve configured the job, you can use the
atq
command to view a list of pending at jobs.
This is shown next:
openSUSE:~ # atq
3 2011-04-02 08:57 a root
If you are logged in as a regular user, the atq command will display only the jobs associated
with the current user account.
If you’re logged in as root, then atq will display all pending jobs for all users.
If you need to remove a pending job from the list, you can use the
atrm job_number
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)
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)
Subscribe to:
Posts (Atom)