584
◾
Linux with Operating System Concepts
also use
crontab –e
to enter all events that you want scheduled and avoid having to
write the file of events.
Similar to at, when crontab runs a task, it must do so with an interpreter. When a
crontab job is submitted, saved with it is the user’s current environment.
The environ-
ment variables saved are HOME, LOGNAME, PATH, and SHELL. This allows the user to
specify an event that uses items in his or her home directory, items in the directories of the
user’s PATH variable, and the log-in shell of that user.
There are /
etc/cron.allow
and /
etc/cron.deny
files that serve the same role as
the allow and deny files for at. If all users can
access crontab, then root would modify cron.
deny to deny certain users access. Alternatively, if no users are allowed to access crontab,
then adding users to cron.allow will provide permission for those users.
Another scheduling approach is to combine crontab with the program
run-parts
.
The run-parts program is given a directory and it executes all the scripts in that directory.
Now, with crontab, we might create an entry that looks like this:
0 0 1 * * run-parts
/
somedirectory
This will execute the scripts found in /
somedirectory
at midnight on the first of every
month. That is, the scripts execute monthly.
One such file that implements this approach is found in /etc/cron.d called
0hourly
. It
specifies that run-parts should execute the contents of /etc/cron.hourly at
01 * * * *
.
This will cause crond to execute the contents (scripts) found in /etc/cron.hourly at 1 minutes
past every hour. If you want to run a script every hour, place that script into the directory
/
etc/cron.hourly
.
Similarly, there are directories of /
etc/cron.daily
, /
etc/cron.
weekly,
and /
etc/cron.monthly
that are set up to execute any scripts in those direc-
tories every day, week, and month, respectively.
14.4 SYSTEM MONITORING
The next step for the system administrator is to ensure that the system is running smoothly.
Specifically, user processes should make progress toward completion in any situation.
Although the system administrator does not have to monitor all running processes all the
time, the system administrator will be called upon if the system is not running as users
expect
and at that time, the system administrator should examine the processes.
14.4.1 Liveness and Starvation
The idea that a process is making progress toward completion is known as
liveness
. To
promote liveness, resources that the process needs to execute must be made available
such that the process is not forced to wait an indefinite period of time for access to that/
those resource(s). The opposite situation is referred to as
starvation
, which means that the
resources that the process needs are continually being withheld from the process.
Resources include access to the operating system, a sufficient amount of main memory,
access to the file system and specific
files within the file system, network access, and most
especially, execution cycles from the CPU. The reason that starvation may arise is subtle
Maintaining and Troubleshooting Linux
◾
585
but has to do with concurrent processing of operating systems (refer back to Chapter 4).
Let us examine why.
Imagine that we have two running processes, P0 and P1, both of which need to operate
on a shared file, F0, which stores the single value 0. P0 is going to read the
file and update
the datum by adding 3 to it. P1 is going to read the file and update the datum by subtracting
2 from it. Both processes will write the datum back to the file. No matter which order P0
and P1 execute, the result should be the value 1 written to the file (0
+
3 – 2
=
1).
However, if the operating system is multitasking, consider the following situation:
1. P0 begins executing, reads the datum from the file, and
stores the datum in a local
variable, X.
2. P0 adds 3 to X. X is now 3 (the file is still storing 0).
3. The CPU is interrupted and the operating system performs a context switch to P1.
4. P1 begins executing, reads the datum from the file, and stores the datum in a local
variable, Y.
5. P1 subtracts 2 from Y. Y is now -2 (the file is still storing 0).
6. P1 writes Y back to the file (the file now stores -2).
7. The CPU is interrupted and the operating system performs a context switch to P0.
8. P0 writes X (3) back to the file (the file now stores 3).
If step 8 occurs before the interruption in step 3, the file will be ok. Alternatively, if step
7 occurs before step 6, then step 6 (P1 writing Y to the file) may occur after step 8, resulting
in the file storing -2. So, we see three possible outcomes from this situation. The file stores
1 (the correct answer), the file stores -2, or the file stores 3.
Since multitasking processes could corrupt data when multiple running processes are
sharing that data, we need to implement a mechanism to ensure that this cannot happen.
We do so by making access
to a shared datum or file
Do'stlaringiz bilan baham: 
