Processes

This session is dedicated to the study of processes.

You don't need to submit source files or reports for this sessions. For this session, you will need to log into a PC running Linux. If you are at Eurecom, simply log on a PC of rooms 52 or 53.

I. Concepts

Open the slides Processes

Watch the video on processes, part 1. There is an exercise to be done during the video (pause the video whenever necessary).

Exercise on states. Use the "Help me" only once you have found answers. You may obvisouly use the web to find answer.

What are the reasons to go from:

Running to Ready ("Ready" is sometimes called "Runnable")?

$ man pthread_yield

Running to Blocked?

Blocked to Ready?

Running to Terminated

Ready to Terminated?

Blocked to Terminated?

Why there is no transition from "Ready" to "Blocked"?

II. Programming processes

Open the slides Processes

Watch the video on processes, part 2. Don't forget to pause the video and to make the exercises (compiling and executing code).

What happens if you execute the following code? I don't ask you to try, but to think about what will happen in the system. You may try if you really want to, but save all your work before ^^

int main(void) {
  while(1) {
    fork()
  }
}

What happens if you replace fork() by vfork() in the previous code?

III. Analyzing processes

The purpose of this exercise is to learn the spawning of new processes. During the lecture on processes, you have been presented how to start a new process from a running one, using the fork() system call. You will practice this system call in this exercise. Don't rush: take your time to really understand what you are doing. Use the "help" only once you have tried your best :)

Logging onto a remote machine. For this exercise, you need to compile, execute your programs and run various commands from another computer named "calibra". Start a terminal, and start a remote login to calibra (in case of problem, another machine may be used: micra):

$ ssh calibra

System calls and fork. Now, try to run the following command:

$ vmstat -s

$ vmstat -s | grep fork

Re-run the same command several times

$ who

C code. Save the fork01.c file into your work directory, open it and understand its code.

Compile fork01.c to a binary file with a name of your choice, but please, select a name that another student won't take, so that you can identify your executable file with a unique name in the system. Let's call it myfork for the description of the lab, but again, name it differently:

$ gcc -o myfork fork01.c

myfork

Warnings. Now, try to compile myfork01.c with the -Wall gcc option:

$ gcc -Wall -o myfork fork01.c

Working with strings. Uncomment the line commented in fork01.c, compile and run again. Do you get an error?

$ strings -t x myfork

$ readelf -S myfork

objdump

$ objdump -s -j section myfork

Writing robust code. We now assume that the system has reached its maximum number of processes: What happens if you execute myfork? Modify your code so as to take into account that problem.

(Help me!) If no more fork is possible in the system, the fork() function returns an error value. Currently, the code I provide does not check the return value of fork(). So, you need to test this value. Probably, "man fork" could help you.

Analyzing calls to library functions and to system calls

Solaris 10/11

dtrace

dtrace-cheatsheet

Full documentation on dtrace

$ dtrace -c myfork -n 'pid$target:::entry'

$ man fflush

"Standard C Library Function"

it is not a system call

$dtrace -n syscall::forksys:entry

$dtrace -n syscall:::entry'/pid == 321/{ @syscalls[probefunc] = count(); }'

mydtracescript

#!/usr/sbin/dtrace -s
pid$1:::entry
{ @count_table[probefunc]=count(); }

$chmod u+x mydtracescript

$./mydtracescript

Advanced call analysis

dtrace

List the number of probes supported by dtrace

(Help me!) /usr/sbin/dtrace -l

List the number of entry probes supported by dtrace that contains the name "fork"

(Help me!) /usr/sbin/dtrace -l -n syscall:::entry|grep fork

Get the number of bytes printed by all processes running in the system

(Help me!) /usr/sbin/dtrace -n 'sysinfo:::writech { @bytes[execname] = sum(arg0); }'

Get the number of bytes printed by your myfork process and its son

(Help me!) /usr/sbin/dtrace -n 'sysinfo:::writech { @bytes[execname] = sum(arg0); }'|grep "myfork"

List of processes started by all users of the system

(Help me!) /usr/sbin/dtrace -n 'proc:::exec-success { trace(curpsinfo->pr_psargs); }'

Print the name of all processes executing a fork

(Help me!) /usr/sbin/dtrace -q -n 'syscall::forksys:entry { printf("%-16s\n",execname); }'

Terminating a process. Now, the father process should terminate (or kill) its son process before it itself terminates. To do so, you could use the kill system call, with as argument the pid of the son process, and the SIGKILL signal. Program this, and test. Also, use dtrace to figure out at which moment the "kill" system call is actually executed. Also, how do you verify that the son process is really killed, that is, that it has not terminated its execution before being killed?

Monitoring signals. Now, we would like to monitor the SIGKILL signals which are sent to processes. Make the following dtrace script, and start it in a terminal:
```
#!/usr/sbin/dtrace -wqs
proc:::signal-send
/args[2] == SIGKILL/
{ printf("SIGKILL was sent to %s by ", args[1]->pr_fname); system("getent passwd %d | cut -d: -f5", uid);
}
```
Then, execute your fork program to see that this script can monitor SIGKILL signals. What information do you get when a process is killed?
Now, we would like to create more than one process

kill function

$ dtrace -c ./myfork -n 'pid$target::fork:entry'

Let's get more information on this Solaris computer!

psrinfo

myfork

pbind

prstat