CSI110

Lecture 3

Process Control

and Management (2)

Reference for this lecture

http://www.afro.caribbean.co.uk/unix-unleashed/unx18.htm

Looking at Processes

• UNIX has several commands to examine and modify the state of processes

• The most common command is ps (report process status)

• Each UNIX system tends to have a slightly different variant of ps - but the two main ones are System V and Berkeley versions

• babe.cs.um.edu.mt supports both versions (/usr/bin/ps = System V version, and /usr/ucb/ps = Berkeley version)

• We will look at the System V variant

ps -f (full listing of user owned processes)

babe% ps -f

UID PID PPID C STIME TTY TIME CMD

csta1 24850 24848 0 11:30:48 pts/0 0:00 -csh

UID: user ID of process owner

PID: process ID

PPID: parent process ID

C: processor utilization for

scheduling (obsolete)

STIME: start time

TTY: terminal attached to process

TIME: CPU time (in seconds)

CMD: command executing

(- means it's executing as a

Checking specific process groups

babe% ps -fg24848

UID PID PPID C STIME TTY TIME CMD

root 24848 153 0 11:30:48 ? 0:00 in.telnetd

• the root user is running the program in.telnetd.

• This is known as a daemon process.

• in.telnetd waits for telnet logins and creates a shell, allowing remote users to login in (it's the TELNET protocol server)

babe% ps -fg153

UID PID PPID C STIME TTY TIME CMD

root 153 1 0 Jan 16 ? 0:07 /usr/sbin/inetd -s

• in.telnetd is owned by inetd - the Internet services daemon - which in turn is owned by init, which is a general process spawner.

babe% ps -fg0

UID PID PPID C STIME TTY TIME CMD

root 0 0 0 Jan 16 ? 0:00 sched

root 1 0 0 Jan 16 ? 0:59 /etc/init -

• init is owned by the process sched which is the very first process created when the system is booted (PID 0)

• sched is the scheduler.

• Without the scheduler, it would be impossible for UNIX to manage more than one process at a time

• Notice that in.telnetd, inetd, init and sched are not attached to terminals (TTY = ?)

• Use ps -ef to list full details of all running processes...

• Use ps -t<terminal> to see all processes attached to the specified terminal (useful to see all processes owned by your shell)

Another example...

• Redirecting Input and Output on UNIX

By default UNIX attaches three special files to each process

stdin: standard input (keyboard)

stdout: standard output (monitor)

stderr: standard error (monitor)

• stdin can be redirected using < symbol (followed by a file or device name), and stdout is redirected using > (again, followed by a file or device name)

• In System V, stderr is redirected using >&, which combines stderr with stdout!

• ps -ef sends output to stdout (the monitor)

• To save results in a file instead, use

ps -ef > filename (errors still sent to monitor). To view the file use cat, more, less, vi, etc...

The example (finally!)

• Find out to which terminal your shell is attached

• Redirect listing of processes attached to the terminal to a file called procs.txt

• List the contents of the file using

cat procs.txt

babe% cat procs.txt

UID PID PPID C STIME TTY TIME CMD

csta1 24949 24947 0 11:52:32 pts/7 0:00 -csh

root 25325 24949 0 12:39:25 pts/7 0:00 ps -ftpts/7

So, what happened?

1. When you typed the ps command at the UNIX prompt, the shell (PID 24949) first performed alias substitution and built-in processing to see if the command was a shell command rather than a UNIX command

2. Those of you who had earlier typed

alias ps /usr/bin/ps to use the System V version of ps had the ps you typed in at the prompt substituted with /usr/bin/ps

3. ps is a UNIX command, so the shell (PID 24949) then instructed UNIX to perform a fork to create a new process (PID 25325). PID 24949 now waits for PID 25325 to terminate.

4. Initially, PID 25325 will be a copy of PID 24949. PID 25325 modifies its process environment to cater for the requested redirection of stdout.

5. PID 25325 asks UNIX to exec the ps command (with its arguments). UNIX overwrites the code and data of PID 25325 with the code and data for the ps command

6. PID 25325 runs the ps command, writing its output to procs.txt

7. When PID 25325 terminates, PID 24949 is notified and prompts the user for more input.

Why is the ps command owned by root?

• From the contents of procs.txt you can see that the owner user id of the ps command is the root user

• ps sometimes needs to access files owned by root which are read/write protected for everyone else, so ps needs to run as if root owns the process so that it will have the same privileges as the root user

• Also see passwd, to change user passwords

Executing background processes

• You can see from the contents of procs.txt that the -csh and ps processes existed simultaneously while ps was executing

• However, -csh waited for ps to terminate before resuming execution (because -csh prompted for user input only when ps finished executing)

• If ps, or any other program you execute, takes a long time, you won't be able to run anything else in the shell

• To overcome this, you can either start a new shell in a new window (or telnet session), or execute the lengthy process in the background - especially if the process is non-interactive - or if you have redirected program input from a file rather than stdin

• If you run a process in the background, the parent process will not wait for the child to terminate

• A message will be sent to the attached terminal when the child terminates

• Terminate the command line with an ampersand (&) to execute a process in the background

ps -ef > procs2.txt &

• The output of the ps command will be saved to proc2.txt, control will be returned to -csh immediately after the fork, and when the ps command terminates the attached terminal will be sent

[1] Done ps -ef > procs3.txt

[1] indicates the background job number

• Do not depend on the output of a background process until you know it has terminated!

• In programs that you write, do not perform output paging - this prevents programs from working properly in the background!