Due Processes

lecture in color

Due processes

Process: one independent program execution.
Every process is generated from an executable program, but
there can be more than one process executing the same exact program.

Process concepts

Process identifier: (PID) a number between 1 and 65535 that uniquely identifies the process
Process parent: the parent that `spawned' this process.
Parent process identifier: (PPID) the process identifier of the parent.

Process rules

Process 1 is special: the init process that starts UNIX.
- process 1 is an ancestor of all processes.
- if process 1 dies, system reboots.
When you invoke a process (by running a command), your shell's process invokes the command as a child process.
Thus the shell is its parent process.

Process groups

Your shell is a process group leader.
This means that whatever you do to it you do to its children.
if your shell dies, so do all children of it.
if you send a signal to your shell, then all children receive it as well.

fork

To create a new process, a process must fork.
This `clones' two identical copies of the same process, executing starting at the same exact place.
The only difference between the processes is that one is parent, one is child.
The fork() call returns the PID of the child to the parent, 0 to the child.
```
 pid = fork(); 
 if (pid!=0) { 
 ... // parent
 } else { 
 ... //child
 } 
```

fork is dangerous!

the following program will freeze whatever server it executes upon.
```
 main() { while (1) fork(); } 
```
Each server can run only a fixed number of processes.
The server will run out of processes and be unable to execute more.
Thus no one can even login to kill the runaway.
The server will only continue running when you control-C the process.
the following program freezes any server upon which you run it until a reboot.
```
 main() { while (1) { if (fork()) exit(0); else fork(); } } 
```
- if (fork()) if I'm a parent
- exit(0) end execution so control-C's won't propogate to children
- else fork() and once you're free of parent, fork again!
Please don't do this to our servers! We'll find out and kick you!

exec

the second phase of process spawning is typically an exec
read a new program
replace the running one with it.
but inherit:
- environment variables
- open file descriptors (any files the previous process was reading or writing)

in C:

 int pid,status; 
 if (pid=fork()) { 
    waitpid(pid,&status,0); // wait for command to finish
 } else { 
    // whatever you want
    execl("/path/to/some/command", "arg1", "arg2", ...);   
 }

wait

The parent has to `reap' its children after they end execution.
To do this the C programmer can call `waitpid' as above.
if a programmer doesn't do this in some way, the child process, when it dies, becomes a zombie (living dead) waiting for a parent to reap it.
zombies disappear only if the parent dies.

Foreground and background

if a process is spawned above, with a wait until its completion, we call it a foreground process.
if the parent doesn't wait for its completion, we call it a background process.
in the shell, we mark background processes with trailing &.

Typical uses of background processes:

Things that take too long to wait for.
Things that must happen all the time.

Example: moving lots of files:

If I type:
```
 cd /g; tar cf - 150NET | (cd /loc/adm; tar xfBp -)
```
this'll have the effect of copying the whole 150NET hierarchy from /g to /loc/adm. This'll take awhile!
If I don't want to wait, I can type:
```
 cd /g; tar cf - 150NET | (cd /loc/adm; tar xfBp -) &
```
The trailing & tells the shell to run this process in the background. I can continue doing other things.

A simple background process

Let's make a simple background process that spies on your mail and tells you when you have new mail. To do this, it'll compare the date on your mailbox with its previous date.
Sketch of code:
- Start by recording the modification date of your mailbox.
- Every 10 seconds, check it against the current modification date.
- If the new date is newer, then write a message to you.

Try this version: (processes/spy.c)

 #include <stdio.h> 
 #include <sys/types.h>
 #include <sys/stat.h>
 
 #define MAIL "/g/150NET/public_html/notes/processes/mail"
 main() { 
   struct stat buf; 
   time_t lastmod; 
   stat(MAIL,&buf); 
   lastmod = buf.st_mtime; 
   while (1) { 
     sleep (10); 
     stat(MAIL,&buf); 
     if (buf.st_mtime>lastmod) { 
       printf("you've got mail!"); 
       exit(0); 
     } 
   } 
 }

stat(file,&buf): find out about a file, place the results into buf.
stat.st_mtime: the seconds between the time the file was last modified and Jan 1 1970 00:00:00 GMT (the birthday of UNIX).

Then we execute:

 blackhole{couch}129: touch mail
 blackhole{couch}130: spy &
 [1] 16248
 ... time passes ...
 blackhole{couch}131: touch mail
 blackhole{couch}132: you've got mail!
 [1]    Done                   spy
 blackhole{couch}132:

touch mail: make mail have the current time as modification time (as if mail arrived).

Background process caveat

Background processes don't die by themselves!
If you write one to, e.g., notify you when your girlfriend logs in, you have to kill it before you log out!
Case history:
- Person wrote C program like the above, put into .cshrc to be started every time they logged in.
- Logged in and out 100 times.
- 100 background processes were running!
- load average on machine was 10!

Jobs

In UNIX, a background process is identified by a PID.
In the shell, however, it also has a job number.
You can see the shell job numbers by typing 'jobs'
Can refer to job numbers with percent: %1 is job 1.
```
 kill %1
```
kills job number 1.

Daemons

most processes are run by and interact with a specific user.
some background processes instead provide services to people on the network.
- no interaction with a user (logged in or not).
- no `controlling terminal' (shell).
to utilize a daemon, you connect to it (from perhaps another machine).

Daemon concepts (IP)

hostname: name of host upon which the daemon executes.
ip address: internet address of the machine upon which the daemon runs.
port: a unique number between 1-65535 that identifies the service the daemon should provide.
/etc/services gives names to these ports.
To contact a daemon, you must specify either hostname or ip address, as well as port.

A simple daemon (in Perl)

allow connections from telnet clients.
give info about a host.

Here's a simple version: (processes/tell.pl)

 #! /local/bin/perl 
 
 use Socket;
 use Carp;
 BEGIN { $ENV{PATH} = '/usr/ucb:/bin' }
 $EOL = "\015\012"; # carriage return/linefeed 
 # how to print out a log message with time and date 
 sub logmsg { print "$0 $$: @_ at ", scalar localtime, "\n" }
 my $port = 2345; # unique identifier for daemon 
 my $proto = getprotobyname('tcp');
 # create a 'socket': a mechanism to accept connections from outside 
 socket(Server, PF_INET, SOCK_STREAM, $proto)        
    || die "socket: $!";
 setsockopt(Server, SOL_SOCKET, SO_REUSEADDR, pack("l", 1))   
    || die "setsockopt: $!";
 # bind this socket to the port number 2345 
 bind(Server, sockaddr_in($port, INADDR_ANY))        
    || die "bind: $!" ;
 # start listening for connections from outside 
 listen(Server,SOMAXCONN)                            
    || die "listen: $!";
 logmsg "server started on port $port";
 my $paddr;
 
 # main loop: accept and process connections 
 for ( ; $paddr = accept(Client,Server); close Client) {
     my($port,$iaddr) = sockaddr_in($paddr);
     my $name = gethostbyaddr($iaddr,AF_INET);
     logmsg "connection from $name [",
           inet_ntoa($iaddr), "]
           at port $port";
     print Client "Hello there, $name, it's now ",
                   scalar localtime, $EOL;
 }

if you run this on, say, foo.eecs.tufts.edu, and then from another host, say:

 telnet foo.eecs.tufts.edu 2345

then the response will be something like:

 blackhole{couch}51: telnet foo.eecs.tufts.edu 2345
 Trying 127.0.0.1...
 Connected to foo.eecs.tufts.edu.
 Escape character is '^]'.
 Hello there, foo.eecs.tufts.edu, it's now Thu Feb  8 14:56:32 2001
 Connection closed by foreign host.
 blackhole{couch}52:

It tells you the time on the remote server!

Not the whole story

This simple daemon doesn't really become a daemon.
Doesn't have to run in the background.
Still has a controlling terminal.
To really become a daemon, we need to eliminate those limits.
For a lot more details on writing daemons, take Comp111/EE128.

Viewing processes

To see your own processes (for your current session):
```
 ps -l
```
or all your processes from all sessions:
```
 ps -efl | grep couch | more
```
where you subsitute yourself for couch.

This might result in:

    couch 15742 15740  0 11:29:45 pts/9    0:01 /usr/bin/tcsh
    couch 11217     1  0   Jan 22 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 14030 13996  0   Jan 24 ?        0:00 /bin/cat /tmp/.removable/notify8
    couch 10112     1  0   Jan 21 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 13996     1  0   Jan 24 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch  6596     1  0   Jan 20 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch  1236     1  0   Jan 18 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15531 15506  0 10:14:15 pts/4    0:01 /usr/bin/tcsh
    couch 15676 15505  0 10:49:49 ??       0:01 /usr/dt/bin/dtterm
    couch  2901  2865  0   Jan 18 ?        0:00 /bin/cat /tmp/.removable/notify0
    couch 15648 15505  1 10:34:12 ??       0:05 /usr/dt/bin/dtterm
    couch 15499 15480  0 10:13:49 pts/2    0:01 /usr/dt/bin/dtsession
    couch 10150 10112  0   Jan 21 ?        0:00 /bin/cat /tmp/.removable/notify4
    couch  1273  1236  0   Jan 18 ?        0:00 /bin/cat /tmp/.removable/notify2
    couch   371     1  0   Jan 17 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15514     1  0 10:14:10 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15691 15690  0 10:51:31 pts/8    0:01 (dns helper)
    couch   414   371  0   Jan 17 ?        0:00 /bin/cat /tmp/.removable/notify1
    couch 15478     1  0 10:13:40 ?        0:00 /usr/dt/bin/dsdm
    couch 16146 15650  0 16:01:00 pts/7    0:00 grep couch
    couch 15480 15477  0 10:13:40 pts/2    0:00 tcsh -c unsetenv _ PWD;     source /u/f/couch/.login;            unsetenv DT;
    couch 15498     1  0 10:13:48 pts/2    0:01 /usr/dt/bin/ttsession
    couch 15425 14791  0 10:13:31 ?        0:01 /bin/ksh /usr/dt/bin/Xsession
    couch 15740 15505  0 11:29:41 ??       0:20 /usr/dt/bin/dtterm
    couch 15477 15425  0 10:13:39 pts/2    0:01 /usr/dt/bin/sdt_shell -c unsetenv _ PWD;     source /u/f/couch/.login;       
    couch  9175     1  0   Jan 21 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15550 15511  0 10:14:18 ?        0:00 /bin/cat /tmp/.removable/notify10
    couch 14790   249 10 19:12:09 ?       10:17 /usr/openwin/bin/Xsun :0 -nobanner -auth /var/dt/A:0-tRaiFa
    couch  6634  6596  0   Jan 20 ?        0:00 /bin/cat /tmp/.removable/notify3
    couch  9214  9175  0   Jan 21 ?        0:00 /bin/cat /tmp/.removable/notify5
    couch 15551 15514  0 10:14:18 ?        0:00 /bin/cat /tmp/.removable/notify9
    couch 13796 13756  0   Jan 24 ?        0:00 /bin/cat /tmp/.removable/notify6
    couch 15435 15425  0 10:13:32 ?        0:00 /usr/openwin/bin/fbconsole
    couch  2865     1  0   Jan 18 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 11264 11217  0   Jan 22 ?        0:00 /bin/cat /tmp/.removable/notify7
    couch 15524 15506  0 10:14:14 pts/3    0:01 /usr/bin/tcsh
    couch 13756     1  0   Jan 24 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15511     1  0 10:14:09 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15505 15499  0 10:13:52 ?        0:26 dtwm
    couch 15566 15506  0 10:14:22 pts/6    0:00 /usr/bin/tcsh
    couch 15557 15506  0 10:14:20 pts/5    0:00 /usr/bin/tcsh
    couch 15506 15499  0 10:14:09 ??       2:18 dtterm -session dtBia4Ra -sdtserver
    couch 15508 15499  0 10:14:09 ?        0:06 sdtperfmeter -f -H -t cpu -t disk -s 1 -name fpperfmeter
    couch 15650 15648  0 10:34:13 pts/7    0:02 /usr/bin/tcsh
    couch 15678 15676  0 10:49:50 pts/8    0:01 /usr/bin/tcsh
    couch 15690 15678  5 10:51:26 pts/8    2:44 netscape http://conbrio/g/150NET/register.html

Communicating with processes

You're used to communicating with processes via the shell.
You can't do that reliably with daemons.
Another mechanism exists to replace shell mechanisms.

Shell process control:

control-C: stop a process completely.
control-Z: suspend a process for future execution.
control-\: stop a process immediately with core dump.
and many others.

Problem with shell mechanisms

To stop a process, you must be typing on its controlling terminal.
daemons may not have controlling terminals.
So you can't stop them this way!

Signals

another mechanism by which one can communicate with a process.
just an integer that the process receives and reacts upon.

here's a list: (andante:/usr/include/sys/signal.h)

 #define SIGHUP        1       /* hangup */
 #define SIGINT        2       /* interrupt (rubout) */
 #define SIGQUIT       3       /* quit (ASCII FS) */
 #define SIGILL        4       /* illegal instruction (not reset when caught) */
 #define SIGTRAP       5       /* trace trap (not reset when caught) */
 #define SIGIOT        6       /* IOT instruction */
 #define SIGABRT       6       /* used by abort, replace SIGIOT in the future */
 #define SIGEMT        7       /* EMT instruction */
 #define SIGFPE        8       /* floating point exception */
 #define SIGKILL       9       /* kill (cannot be caught or ignored) */
 #define SIGBUS        10      /* bus error */
 #define SIGSEGV       11      /* segmentation violation */
 #define SIGSYS        12      /* bad argument to system call */
 #define SIGPIPE       13      /* write on a pipe with no one to read it */
 #define SIGALRM       14      /* alarm clock */
 #define SIGTERM       15      /* software termination signal from kill */
 #define SIGUSR1       16      /* user defined signal 1 */
 #define SIGUSR2       17      /* user defined signal 2 */
 #define SIGCLD        18      /* child status change */
 #define SIGCHLD       18      /* child status change alias (POSIX) */
 #define SIGPWR        19      /* power-fail restart */
 #define SIGWINCH      20      /* window size change */
 #define SIGURG        21      /* urgent socket condition */
 #define SIGPOLL       22      /* pollable event occured */
 #define SIGIO SIGPOLL /* socket I/O possible (SIGPOLL alias) */
 #define SIGSTOP       23      /* stop (cannot be caught or ignored) */
 #define SIGTSTP       24      /* user stop requested from tty */
 #define SIGCONT       25      /* stopped process has been continued */
 #define SIGTTIN       26      /* background tty read attempted */
 #define SIGTTOU       27      /* background tty write attempted */
 #define SIGVTALRM     28      /* virtual timer expired */
 #define SIGPROF       29      /* profiling timer expired */
 #define SIGXCPU       30      /* exceeded cpu limit */
 #define SIGXFSZ       31      /* exceeded file size limit */
 #define SIGWAITING    32      /* process's lwps are blocked */
 #define SIGLWP        33      /* special signal used by thread library */
 #define SIGFREEZE     34      /* special signal used by CPR */
 #define SIGTHAW       35      /* special signal used by CPR */
 #define SIGCANCEL     36      /* thread cancellation signal used by libthread */
 #define SIGLOST       37      /* resource lost (eg, record-lock lost) */

Kill

Processes are manipulated directly via the kill command (which does a lot more than just kill processes).
All kill really does is to send a specified signal to a process.
One can send signals that tell a process to die, or mean other things.
For the most part, the process interprets the signal as it wishes.
So meanings are almost always process-dependent.
Only exceptions: SIGTERM and SIGKILL always mean to die.

Map between shell and kill

to see what mapping is, type 'stty -a':

 conbrio{couch}172: stty -a
 speed 9600 baud; 
 rows = 30; columns = 80; ypixels = 400; xpixels = 570;
 eucw 1:0:0:0, scrw 1:0:0:0
 intr = ^c; quit = ^\; erase = ^?; kill = ^u;
 eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
 start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
 rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
 -parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext 
 -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc 
 ixon -ixany -ixoff imaxbel 
 isig icanon -xcase echo echoe echok -echonl -noflsh 
 -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten 
 opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel tab3

control-C: SIGINT (2)
control-\: SIGQUIT (3)
control-Z: SIGSTOP (23)
To mimic control-C'ing a program with PID 300, one could type
```
 kill -INT 300
```
or
```
 kill -2 300
```
etc.

Problem of the day #1

what kill command mimics shell control-Z?
How could one perform
```
 kill -23 300
```
if one was connected to process 300 in a shell?

Using kill

Shut down a process gracefully:
```
 kill 15566
```
would end one of my shells (that I might be typing within at the time). The default is to send SIGTERM (15).
Shut down a process rudely and with no recourse:
```
 kill -9 15566
```
or
```
 kill -KILL 15566
```
This gives the process no choice; it can't block or ignore the request (as it can with the above signal).
Tell a process something has changed.
```
 kill -HUP 15566
```
sends a HANGUP signal to a process. This means the connection hung up.
SIGHUP is often interpreted specially by daemons.
The convention is that if you HANGUP a daemon, it will not stop, but will re-read all its data from disk.

Process Tasks

Typical task: log yourself off of a machine remotely.
Comment: you're logged off if you have no processes at all.

Find your processes:

 % ps -ef | grep couch
    couch 15742 15740  0 11:29:45 pts/9    0:01 /usr/bin/tcsh
    couch 11217     1  0   Jan 22 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 14030 13996  0   Jan 24 ?        0:00 /bin/cat /tmp/.removable/notify8
    couch 10112     1  0   Jan 21 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 13996     1  0   Jan 24 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch  6596     1  0   Jan 20 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch  1236     1  0   Jan 18 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15531 15506  0 10:14:15 pts/4    0:01 /usr/bin/tcsh
    couch 15676 15505  0 10:49:49 ??       0:01 /usr/dt/bin/dtterm
    couch  2901  2865  0   Jan 18 ?        0:00 /bin/cat /tmp/.removable/notify0
    couch 15648 15505  1 10:34:12 ??       0:05 /usr/dt/bin/dtterm
    couch 15499 15480  0 10:13:49 pts/2    0:01 /usr/dt/bin/dtsession
    couch 10150 10112  0   Jan 21 ?        0:00 /bin/cat /tmp/.removable/notify4
    couch  1273  1236  0   Jan 18 ?        0:00 /bin/cat /tmp/.removable/notify2
    couch   371     1  0   Jan 17 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15514     1  0 10:14:10 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15691 15690  0 10:51:31 pts/8    0:01 (dns helper)
    couch   414   371  0   Jan 17 ?        0:00 /bin/cat /tmp/.removable/notify1
    couch 15478     1  0 10:13:40 ?        0:00 /usr/dt/bin/dsdm
    couch 16146 15650  0 16:01:00 pts/7    0:00 grep couch
    couch 15480 15477  0 10:13:40 pts/2    0:00 tcsh -c unsetenv _ PWD;     source /u/f/couch/.login;            unsetenv DT;
    couch 15498     1  0 10:13:48 pts/2    0:01 /usr/dt/bin/ttsession
    couch 15425 14791  0 10:13:31 ?        0:01 /bin/ksh /usr/dt/bin/Xsession
    couch 15740 15505  0 11:29:41 ??       0:20 /usr/dt/bin/dtterm
    couch 15477 15425  0 10:13:39 pts/2    0:01 /usr/dt/bin/sdt_shell -c unsetenv _ PWD;     source /u/f/couch/.login;       
    couch  9175     1  0   Jan 21 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15550 15511  0 10:14:18 ?        0:00 /bin/cat /tmp/.removable/notify10
    couch 14790   249 10 19:12:09 ?       10:17 /usr/openwin/bin/Xsun :0 -nobanner -auth /var/dt/A:0-tRaiFa
    couch  6634  6596  0   Jan 20 ?        0:00 /bin/cat /tmp/.removable/notify3
    couch  9214  9175  0   Jan 21 ?        0:00 /bin/cat /tmp/.removable/notify5
    couch 15551 15514  0 10:14:18 ?        0:00 /bin/cat /tmp/.removable/notify9
    couch 13796 13756  0   Jan 24 ?        0:00 /bin/cat /tmp/.removable/notify6
    couch 15435 15425  0 10:13:32 ?        0:00 /usr/openwin/bin/fbconsole
    couch  2865     1  0   Jan 18 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 11264 11217  0   Jan 22 ?        0:00 /bin/cat /tmp/.removable/notify7
    couch 15524 15506  0 10:14:14 pts/3    0:01 /usr/bin/tcsh
    couch 13756     1  0   Jan 24 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15511     1  0 10:14:09 ?        0:00 /bin/ksh /usr/dt/bin/sdtvolcheck -d -z 5 cdrom
    couch 15505 15499  0 10:13:52 ?        0:26 dtwm
    couch 15566 15506  0 10:14:22 pts/6    0:00 /usr/bin/tcsh
    couch 15557 15506  0 10:14:20 pts/5    0:00 /usr/bin/tcsh
    couch 15506 15499  0 10:14:09 ??       2:18 dtterm -session dtBia4Ra -sdtserver
    couch 15508 15499  0 10:14:09 ?        0:06 sdtperfmeter -f -H -t cpu -t disk -s 1 -name fpperfmeter
    couch 15650 15648  0 10:34:13 pts/7    0:02 /usr/bin/tcsh
    couch 15678 15676  0 10:49:50 pts/8    0:01 /usr/bin/tcsh
    couch 15690 15678  5 10:51:26 pts/8    2:44 netscape http://conbrio/g/150NET/register.html

Then kill all of them:

 % kill -9 15742 11217 14030 10112 13996 6596 1236 15531 15676 2901 15648 \
 15499 10150 1273 371 15514 15691 414 15478 16146 15480 15498 15425 15740 \
 15477 9175 15550 14790 6634 9214 15551 13796 15435 2865 11264 15524 13756 \
 15511 15505 15566 15557 15506 15508 15650 15678 15690

Or for the lazy and esoterically inclined:
```
 kill -9 `ps -ef | awk '$1=="couch" { print $2 }'`
```
- The backquote syntax:
```
 `ps -ef | awk '$1=="couch" { print $2 }'`
```
  executes the command
```
 ps -ef | awk '$1=="couch" { print $2 }'
```
  and substitutes its output inline! This is the process list.
- ps -ef generates the list of all processes, while
```
 awk '$1=="couch" { print $2 }'
```
  selects only the lines with couch in the first field, and then prints the second field (the process ID).
This logs you out of all sessions, including the one you're typing within.

Inside a process

physical and virtual memory.
memory mapping.

Processes occupy memory.

Two kinds of memory: physical and virtual.
physical: actually installed in the machine.
virtual: memory on disk that substitutes for physical memory.
virtual memory is also called `swap'.

Mapping:

When a process runs, it acquires memory in `pages' of 4096 bytes each.
These pages are mapped to form its private process space.
From the process point of view, its memory is from 0x00000000 to 0xffffffff (with a big hole in the middle).

Rough map of a UNIX process:

 0x00000000 |---TEXT----|--GLOB--|----DATA---->| ..... |<---STACK-----| 0xffffffff
             read                 heap:          blank!  subroutine
              only                 malloc and             arguments
               program              new manage             and variables

TEXT: read only program storage (including shared libraries)
DATA: the memory heap. Used by malloc and free, new and delete
GLOB: global variables.
STACK: the execution stack: used to store subroutine calls.

Dynamic model of process memory

start by mapping TEXT, GLOB, DATA, and STACK segments.
DATA expands upward as process requires more memory.
STACK expands downward as process makes more subroutine calls.
space between DATA and STACK is unassigned

Cryptic C and C++ error messages explained!

Segmentation fault: you tried to do something with the memory in the hole between DATA and STACK. Since it isn't mapped until needed, it isn't physically there until you request it with new, malloc, or a subroutine call!
Bus error: you tried to write into the TEXT segment. This is a no-no. The reason that it's called a bus error is that you're telling the data bus to write when it can only read.
core dumped is not an error message but information. It tells you that the operating system made a `snapshot' of your whole process space so you could look at what happened. This file is called `core'. Since it includes not only your program, but all data it created in the process of running, this file can be very large.

Process execution model:

Start with a `free pool' of 4096-byte physical and virtual pages.
This is all of real memory that isn't used so far.
When a process executes, create its map of memory as a mix of physical and virtual pages.
In order to execute code or access data in a virtual page, the page containing that data must become physical.
When data or code isn't needed, the page containing it can become virtual.
The process of changing each process's map so that pages become physical or virtual as needed is called paging or swapping.
The most common algorithm for swapping is called least recently used or LRU.

LRU Swapping

Keep track of the last time a process used a page.
When a process needs to access something that's virtual,
- If there's an unused physical page available, swap the virtual page into physical memory and out of virtual memory.
- Else first swap out the page that was accessed least recently

lecture in color

/comp/150NET/notes/processes.php
downloaded on Nov-23-2009 03:29:36 PM,
was last modified on Feb-17-2004 10:49:16 PM.
All lecture note content is copyright 2004 by
Alva L. Couch, Computer Science, Tufts University