Corning Community College CSCS1730 UNIX/Linux Fundamentals Lab 0x7: Job Control and Multitasking ~~TOC~~ =====Objective===== To become familiar with the multitasking capabilities of UNIX/Linux systems. =====Note===== Although one UNIX system implementations have a lot in common, within each implementation there are differences. These can range from kernel or library call implementations all the way down to particular behaviors (or default behaviors) of commands to the organization of system scripts. With this in mind, we have the potential to encounter some of those differences with respect to the **ps**(**1**) utility. Depending on the type of system you are on (or documentation you are referencing) potentially both the behavior and arguments to **ps**(**1**) may vary. So be wary if the book(s) indicate a particular invocation of **ps**, and you see a different result on lab46. Be sure to reference the manual page for **ps**(**1**) on lab46 for best results. =====Reading===== In "UNIX for the Beginning Mage", please read: * Chapter 8, pages 85-94. In "Harley Hahn's Guide to UNIX and Linux", please read: * Chapter 26 ("Processes and Job Control", pages 767-816). In "Learning the UNIX Operating System, 5th Edition", please read: * Chapter 7 ("Multitasking", page 130-135). =====Background===== UNIX is a multitasking, multiuser operating system. So far in this course you have dealt with the multiuser aspect of the system (through the **who**(**1**) utility from [[/haas/spring2014/unix/labs/lab0|Lab #0]] and with the **write**(**1**), **talk**(**1**), and **ytalk**(**1**) utilities. Through this usage you have seen that many users can be on the system simultaneously, each doing individual tasks. So what is multitasking? Multitasking is the ability of the system's processor to allocate cycles of CPU time efficiently enough in order to give the appearance that many processes are running simultaneously. ====What is a process?==== A process is the term given to a running UNIX application (ie a "program in action"). UNIX provides a mechanism for viewing these processes running in memory. The **top**(**1**) and **ps**(**1**) utilities allow you to view various perspectives of the process list. ====Terminology==== Instead of saying "list of running programs", you would say "the process list". You can manipulate the process, as it is a unique instance of a real program on the system. In a way, the multiuser aspect of UNIX already proves it is multitasking, as each user is doing their own task independent of any other user. However, each user can multitask their own session. This ability to run and manage more than one process within your login terminal is known as **Job Control**. ====More Terminology==== Some additional terminology you should be familiar with: * **__Process ID (PID)__**: a unique number assigned to each running process on the system. * **__Foreground process__**: a process that is running in the foreground (currently using STDIN/STDOUT/STDERR). * **__Background process__**: a process that is running independently in the background, allowing you to use your shell (which is in your foreground) or start additional applications. * **__killing a process__**: in UNIX, you can terminate processes with the **kill**(**1**) utility. =====Viewing Processes===== The **ps**(**1**) is used to list the running processes on the system. Running with no arguments will show the current processes attached to your login session. ^ 1. ^|Do the following:| | ^ a.|List your current processes with **ps**(**1**). How did you do this? (Provide the output)| |:::^ b.|If you were logged onto the system multiple times, would your invocation of **ps**(**1**) also show any processes being run in your other shells?| |:::^ c.|How would you instruct **ps**(**1**) to give you this information?| **ps**(**1**) can also be used to list all the processes on the system. ^ 2. ^|Do the following:| | ^ a.|Using **ps**(**1**), list all processes on the system in user-oriented format. Tell me how you did it.| |:::^ b.|What PID is the process **inetd** (inet daemon)? Include the entire matching line from **ps**.| |:::^ c.|Run **top**(**1**), and check it out for a while. Any observations? What are the most active processes? (q to quit)| ====Running in the background==== When used by itself following a command on the command-line, the **&** will instruct the shell to run the command in the background. For example: lab46:~$ head -n4 /etc/motd > file1 & [1] 12956 lab46:~$ Instead of **12956**, you will get the next available process number at the time of execution. Will take the first 4 lines of **/etc/motd** and redirect its STDOUT to a file called **file1**. This will run in the background, and will give the PID of the process. This particular command-line should complete quickly. In the **multitask/** subdirectory of the UNIX Public Directory, you will find the **count.c** file. Copy it to your home directory and take a look at it. ^ 3. ^|Using the tools available to you, determine:| | ^ a.|What type of file is this? How did you determine this?| |:::^ b.|Follow the instructions inside on how to compile it to create an executable.| |:::^ c.|Did it work? How do you run it?| |:::^ d.|What could you do to make your $PATH see this executable file? Explain.| NOTE: If you have problems, there is an existing binary (called **count**) located in the same place you found **count.c** Now let us compare the benefits of using the **&** to background processes: ^ 4. ^|Do the following:| | ^ a.|Run: **time ./count > output** and wait for it to finish. What is in "**output**"? How long did it take?| |:::^ b.|Do the same, but this time add an **&** to the end. Anything change? Get a process listing with top, does it show up? What is its CPU utilization?| ====The Command Separator==== The command separator is another useful feature, represented as a semi-colon (**;**). You can use this to string commands together to execute one after the other. For example: lab46:~$ ls -l; cat /etc/motd Will execute **ls** with the **-l** argument, then once it is complete, will go and cat out the contents of **/etc/motd**. Each command is run separately, and therefore has its own unique PID. ====Command Grouping per process==== Finally, the parenthesis come in use. If you enclose an entire command-line in parenthesis (excluding the &, as seen on page 132 in Learning the UNIX Operating System, 5th Edition) will cause the shell to treat that sequence of commands as one unique command, and give ALL commands involved just one unique PID! =====Task 1===== Devise a command-line to do the following: * using **sleep**(**1**) * delay for 8 seconds before running **ls**(**1**) * when **ls**(**1**) is run, it should list all the files in **/var** * the output of the **ls**(**1**) should be redirected into a file, in your home directory, called: **multitask.lab.txt** * make sure this whole task runs in the background Confused? Be sure to ask questions. ^ 5. ^|Devise a command-line to implement task 1:| | ^ a.|Show me the command-line incantation you came up with, and explain your reasoning.| =====Job Control: Suspending a foreground process===== Not only can you background processes, but you can suspend and manipulate foreground processes. By using the SUSPEND character, you can cause most applications running in the foreground to stop, giving you back control of you prompt. When at the prompt using the bourne shell, you can use the built-in command jobs to list any suspended jobs that can be manipulated. If you have any, they will be preceded by a job number, allowing you to foreground (fg) or background (bg) that job. =====Task 2===== Set up the following situation: * Run "**cat -**" at the Lab46 prompt. * Once it is running, hit **CTRL-Z** to suspend it. * Then, once you get the prompt back, run "**links http://localhost &**" * Type "**jobs**" to see the list of jobs currently running in your session. So far we've put some things in the background, and if we're lucky, we'll just have gotten a message from the shell. ^ 6. ^|Do task 2, along with the following:| | ^ a.|Try logging out by hitting **CTRL-D**.| |:::^ b.|Are you able to immediately log out?| |:::^ c.|What happens?| |:::^ d.|What might be the purpose behind this action by the shell?| If you ended up logging out, please repeat **Task 2** to do the following question. ^ 7. ^|Let's do some diagnostics:| | ^ a.|What number is the links job?| |:::^ b.|Type fg # to foreground it. Did it work? Suspend it again.| |:::^ c.|Is links still listed in the jobs list?| |:::^ d.|Foreground the cat job and tell me how you did it.| |:::^ e.|With cat running in the foreground, end it with the end of file character.| |:::^ f.|Is cat still listed in the jobs list?| |:::^ g.|Foreground and end links (you may have to use the interrupt character)| |:::^ h.|Is the jobs list empty?| Once the jobs list is empty, you should be able to logout again without a problem. Test this then log back in again to continue with the lab. =====Killing Processes===== Finally, we are going to determine how to terminate processes on the system using the kill(1) utility. The kill utility works on a series of signals that applications use to communicate with the operating system. The most common signals you will encounter are the **Hangup** (**SIGHUP**), **Kill** (**SIGKILL**), and **Terminate** (**SIGTERM**) signals. Hangup is one of the lowest level signals. It instructs the process to re-run, often used to get programs to re-read configuration files. Kill is among the most powerful of the signals as far as normal processes go. When used on a running process, it basically means "kill process with no mercy" -- instant and immediate termination. Terminate is the default signal, when none are supplied. It informs the process that it is to terminate, allowing the process to clean up and take care of any matters it needs to attend to before it exits. kill understands a series of signals, but for the purposes of this class we will only be dealing with the above 3 on a regular basis. ^ 8. ^|Running **kill -l** (lowercase L) on the command line, answer me the following:| | ^ a.|What number is the **Hangup** signal?| |:::^ b.|What number is the **Terminate** signal?| |:::^ c.|What number is the **Kill** signal?| |:::^ d.|What number is the **Interrupt** signal?| ^ 9. ^|Do the following:| | ^ a.|Log in again, so you have two instances of your user logged into the system. Are both instances listed in a **who**(**1**) output? Show me your output.| |:::^ b.|Using the **tty**(**1**) utility, determine the terminal device of both login sessions. What are they?| |:::^ c.|Using the **x** argument to **ps**(**1**), determine the PID of both your login shells. What are they? (Associate PID with terminal device).| Now that we've viewed the current situation, let's change it up a bit: ^ 10. ^|Do the following:| | ^ a.|Using **kill**(**1**), terminate one of your login sessions.| |:::^ b.|Which one did you kill and how did you do it?| |:::^ c.|Any messages generated to your console, and what ones if so?| |:::^ d.|Using **who**(**1**), are you still logged in twice?| Process management is an important feature of any multitasking operating system. Having a handle on how it works not only helps you to better understand how to use UNIX, but to better manage your resources on a system. =====Applying your skills===== Putting these new skills together with those learned in prior weeks, we can start to make the system work for us: ^ 11. ^|Using **ps**(**1**) and **grep**(**1**), figure out (and tell me how you got) the following:| | ^ a.|All the processes on the system that are owned by user **statd**.| |:::^ b.|The PID of the **init** process. Anything noteworthy about the PID this process?| |:::^ c.|Who owns the **cron** process and what is its PID? What purpose does **cron**(**1**) serve on the system?| HINT: pipes are good. And be sure to list your incantations. There are additional commands that deal with processes on the system. You may want to familiarize yourself with the **pkill**(**1**) and **pgrep**(**1**) utilities. =====Conclusions===== This assignment has activities which you should tend to- document/summarize knowledge learned on your Opus. As always, the class mailing list and class IRC channel are available for assistance, but not answers.