\documentclass[11pt]{article} \setlength{\oddsidemargin}{0in} \setlength{\evensidemargin}{0in} \setlength{\topmargin}{0.0in} \setlength{\headheight}{0in} \setlength{\headsep}{0in} \setlength{\textwidth}{6.5in} \setlength{\textheight}{9.0in} \setlength{\parindent}{0in} \setlength{\parskip}{0.12in} \usepackage{times} \usepackage{html} \begin{rawhtml} \end{rawhtml} \begin{document} \title{Unix Processes} \author{Norman Matloff \\ Department of Computer Science \\ University of California at Davis} \date{} \maketitle \tableofcontents \section{Unix Processes} A {\bf process} is an instance of running a program. If, for example, three people are running the same program simultaneously, there are three processes there, not just one. In fact, we might have more than one process running even with only person executing the program, because (you will see later) the program can ``split into two,'' making two processes out of one. Keep in mind that all Unix commands, e.g. {\bf cc} and {\bf mail}, are \underline{programs}, and thus contribute processes to the system when they are running. If 10 users are running {\bf mail} right now, that will be 10 processes. At any given time, a typical Unix system will have many active processes, some of which were set up when the machine was first powered up. Every time you issue a command, Unix starts a new process, and suspends the current process (the C-shell) until the new process completes (except in the case of {\bf background processes}, to be discussed later). Unix identifies every process by a Process Identification Number (pid) which is assigned when the process is initiated. When we want to perform an operation on a process, we usually refer to it by its pid. Unix is a {\bf timesharing} system, which means that the processes take turns running. Each turn is a called a {\bf timeslice}; on most systems this is set at much less than one second. The reason this turns-taking approach is used is fairness: We don't want a 2-second job to have to wait for a 5-hour job to finish, which is what would happen if a job had the CPU to itself until it completed.\footnote{The basic mechanism for setting up the turns is as follows. The machine will have a piece of hardware which sends electrical signals to the CPU at periodic intervals. These signals force the CPU to stop the program it is running, and jump to another program, which will be the operating system program (OS). The OS can then determine whether the current program's timeslice is finished, and if so, then give a turn to another program, by jumping to that program. Note the interaction of hardware (the electrical signals, and the CPU's reaction to them) and software (the OS) here.} \section{Determining Information About Current Processes} The `ps -x' command will list all your currently-running jobs. An example is: \begin{verbatim} PID TT STAT TIME COMMAND 6799 co IW 0:01 -csh[rich] (csh) 6823 co IW 0:00 /bin/sh /usr/bin/X11/startx 6829 co IW 0:00 xinit /usr/lib/X11/xinit/xinitrc -- 6830 co S 0:12 X :0 6836 co I 0:01 twm 6837 co I 0:01 xclock -geometry 50x50-1+1 6841 p0 I 0:01 -sh[rich on xterm] (csh) 6840 p1 I 0:01 -sh[rich on xterm] (csh) 6842 p2 S 0:01 -sh[rich on login] (csh) 6847 p2 R 0:00 ps -x \end{verbatim} The meaning of the column titles is as follows: \begin{verbatim} PID process identification number TT controlling terminal of the process STAT state of the job TIME amount of CPU time the process has acquired so far COMMAND name of the command that issued the process \end{verbatim} The TT information gives terminal names, which you can see by typing the {\bf who} command. E.g. we see p2 in the TT column above, which is the terminal listed as ttyp2 in the {\bf who} command. The state of the job is given by a sequence of four letters, for example, `RWNA'. The first of these four is typically one of the following: first letter runnability of the process R runnable process T stopped process S process sleeping for less than about 20 seconds I processes that are idle (sleeping longer than about 20 seconds) A state-R process is runnable, i.e. it is be able to make use of a turn given to it, and is waiting for one. We can put a process in state T, i.e. stop the process, by typing control-z. Suppose, for example, that I am using {\bf ftp} to get some files from some archive site, and I notice a file there called README. I can use the {\bf ftp} `get' command to get the README file, and then type C-z. This will stop (suspend) the {\bf ftp} process, and get me back to the C-shell. At that point I can read the README file, say using {\bf more}, and then reactivate the {\bf ftp} process, by typing `fg' to the shell. A typical example of an S/I process is one that is waiting for user input. If I am using the {\bf emacs} editor, for example, the process will go to state S when it is waiting for me to type something; if I take more than 20 seconds to decide what to type, the process will be in state I. \section{Foreground/Background Processes} Suppose we want to execute a command but do not want to wait for its completion, i.e. we want to be able to issue other commands in the mean time. We can do this by specifying that the command be executed in the background. There are two ways to do this. The first is to specify that it be a background process when we submit it, which we can do by appending an ampersand (`\&') to the end of the command. For example, suppose we have a very large program, which will take a long time to compile. We could give the command \begin{verbatim} cc bigprog.c & \end{verbatim} which will execute the compilation while allowing me to submit other commands for execution while the compile is running. The C-shell will let me know what the pid is for this background process (so that I can later track it using {\bf ps}, or kill it), but will also give me my regular prompt, inviting me to submit new commands while the other one is running. \footnote{Keep in mind, though, that there is ``no free lunch'' here. The more processes on the machine, the longer it is between turns for each process, so overall response time goes down.} But what about the compiler error messages? We hope we don't have any :-) but if we do have some, we don't want them to be interspersed with the output of other commands we are running while the compile is executing. To avoid this, we redirect the error messages: \begin{verbatim} cc bigprog.c >& errorlist & \end{verbatim} All error messages will now be sent to the file `errorlist', which we can view later.\footnote{Though a much better solution to the problem is to use {\bf emacs}, since the error messages will automatically be placed into a special buffer.} Another good example is when we start a window during a X session. We would like to start the window from an existing window, but we still want to be able to use the original window. We execute the command \begin{verbatim} xterm & \end{verbatim} This will start a new window, and allow us to keep using the current window. The other way to put a job in the background is to stop it, using C-z as described earlier, and then use another command, {\bf bg}, to move the process to the background. For example, suppose we started our long-running compile, \begin{verbatim} cc bigprog.c \end{verbatim} but we forget to append the ampersand. We can type control-z to suspend/stop the job, and then type `bg' to resume the job in the background, allowing us to submit other commands while the compilation takes place. Unix will tell us when the background job has completed, with a statement like \begin{verbatim} [1] Done cc bigprog.c \end{verbatim} By the way, if you log out, whatever background processes you have running at the time will \underline{not} be killed; they will continue to run. \section{Terminating a Process} We can terminate a process by using the {\bf kill} command. We simply find its pid (say by using {\bf ps}), and then type \begin{verbatim} kill -9 pid \end{verbatim} If the process is in the foreground, though, the easiest way to kill it is to simply type control-C. \end{document}