Sequence 1: Job Control

[student@stationX ~]$ su –

Begin some jobs in the background:

[root@stationX ~]# tail -n0 -f /var/log/messages &

[root@stationX ~]# updatedb &

[root@stationX ~]# service syslog restart

[root@stationX ~]# jobs

[root@stationX ~]# kill %1

[root@stationX ~]# jobs

Next, start an instance of vim

[root@stationX ~]# vim

While in vim, press Ctrl-z to suspend the current program.

Run jobs again and note vim’s job ID.

[root@stationX ~]# fg 3

Sequence 2: Conditional Execution

ping -c1 -w2 $TARGET &> /dev/null

vi ~/bin/



ping -c1 -w2 $TARGET &> /dev/null

 [student@stationX ~]$ chmod a+x ~/bin/

[student@stationX ~]$ server1; echo $?


[student@stationX ~]$ station100; echo $?


5. Now use the conditional operators && and || to report success or failure based on ping’s exit value.



ping -c1 -w2 $TARGET &> /dev/null &&

echo “$TARGET is UP” ||

echo “$TARGET is DOWN”

6. [student@stationX ~]$ server1; echo $?

server1 is UP


[student@stationX ~]$ station100; echo $?

station100 is DOWN


7. The script returns 0 for both tests because the last command run is now echo, not ping. Since echo does not fail, it returns success.

8. Modify the script again



ping -c1 -w2 $TARGET &> /dev/null


if [ $RESULT -ne 0 ]


echo “$TARGET is DOWN”


echo “$TARGET is UP”


exit $RESULT

9. Test the script.

[student@stationX ~]$ server1; echo $?

server1 is UP


[student@stationX ~]$ station100; echo $?

station100 is DOWN


[student@stationX ~]$ sudo mv ~/bin/ /usr/local/bin/

Sequence 3: Scheduling One-Time Jobs

Scenario: In this sequence you will schedule a job for one-time execution at a specified

time using the tool you developed in the previous sequence.


  1. Start in a shell, either on a virtual console or a graphical shell, such as gnome-terminal. You should be signed in as student.
  2. Schedule your tool to check all stations five minutes from now:

[student@stationX ~]$ at now+5min

at> for x in $(seq 1 40); do

at> station$x

at> done

at> Ctrl-d

job 7 at 2007-01-23 08:40

Note: Since your script only emits output when there is a problem, you do not have to worry about redirecting STDOUT or STDERR in regular usage. Your job will only notify you of unreachable stations!

  1. The system responded with a job number, but list your scheduled jobs to see any others that you may have created (or that root may have created for you!):

[student@stationX ~]$ at -l

job 7 at 2007-01-23 08:40 a student

  1. For detailed information, cat the job:

[student@stationX ~]$ at -c 7

Read the output, observing that each at job stores the environment for the user that created the job. The job’s command is listed near the bottom of the output.

  1. Optionally, watch the job list until your job executes.

[student@stationX ~]$ watch -n1 ‘at -l’

  1. Check your mail after the job executes to review its output.

[student@stationX ~]$ mutt

Sequence 4: Finding Processes

Scenario: In this sequence you will find the process on your system that is using the most CPU time. Finding it will require the use of ps and tail.


  1. Start in a shell, either on a virtual console or a graphical shell, such as gnome-terminal. You should be signed in as student.
  2. Review the ps man page to find the standard format specifier for displaying the PID, program name, and percent CPU utilization.

man ps

Within the man page, search for the -o option:


Press n until you find the section on the -o option. Instead of listing the available columns, it refers you to the STANDARD FORMAT SPECIFIERS section of the man page, so try searching for that at this point:


Find the list of columns to determine which codes are appropriate.

  1. List all processes on your system, limiting output to PID, program name, and percent CPU utilization.

ps axo pid,comm,pcpu

You should see a long list of processes scroll by.

  1. Now open up the man page for ps to determine if it has the ability to sort output.

man ps


  1. Once you find the correct sort option, add it to your previous command:

ps axo pid,comm,pcpu –sort=pcpu

  1. The output looks right, so now pipe it through another command to restrict output to a single process:

ps axo pid,comm,pcpu –sort=pcpu | tail -n1

Sequence 5: Recurring Jobs

Scenario: In this sequence you will take the command you developed in the previous sequence and adapt it for use in a recurring job. You would like the output mailed to student’s email complete with column headings.


  1. Observing that ps automatically outputs column headings, review the man page to determine how to reverse the sort order, such that the job with the most CPU time is at the top of the output, along with the column headings. Add the reverse sort indicator (-) in front of the sort column:

ps axo pid,comm,pcpu –sort=-pcpu

  1. Now restrict output to the top two lines:

ps axo pid,comm,pcpu –sort=-pcpu | head -n2

The output is now suitable for job scheduling.

  1. Review the man page for crontab to check the field order:

man crontab

  1. Oops! There are two man pages for crontab, so open up the one in section 5, which deals with configuration files:

man 5 crontab

  1. Use information in the man page to determine how would you write a crontab entry that should run every five minutes?

*/5 * * * *

  1. Use your answer to the previous question to add a crontab entry that runs the ps command from earlier every five minutes.

You can do this either by running crontab -e and using a text editor or by piping directly to crontab like this:

echo ‘*/5 * * * * ps axo pid,comm,pcpu –sort=-pcpu | head -n2’ | crontab

  1. Once you have added the job, list your crontab to confirm:

crontab -l

  1. Now add lines to run your command on server1 and station100 every two minutes. Because /usr/local/bin is not in the PATH used by cron, you will need to use an absolute path to the script. Your crontab should now look like this:

*/5 * * * * ps axo pid,comm,pcpu –sort=-pcpu | head -n2

*/2 * * * * /usr/local/bin/ server1

*/2 * * * * /usr/local/bin/ station100

  1. Once a few minutes have passed, check your mail with the mutt command to see the output of your jobs. See the instructions at the beginning of this lab if you are unfamiliar with mutt.

Some observations about what you should see:

  • You did not receive any mail regarding the reachability of server1; your script correctly avoids output on successful completion
  • You received at least one message regarding the failure to reach station100
  1. For cleanup, remove your crontab:

crontab -r; crontab -l