Agenda  Working with Processes: Purpose Running Programs within same process (execl, execlp, execle, execv, execvp, execve) “Spawning” other process (fork, wait, waitpid) Examples  Working with Signals: Purpose Commands (signal, pause, raise, sigaction) Examples

Processes  A process is the memory space and settings with which a program runs.  Data and programs are stored in files on the disk and programs run in processes. File System / bin etc home UNIX OS Memory (User Space)Hard Disk Process (PID#): Stores running program & related data

Processes  There are many processes that run in the Unix OS:  Upon Unix OS startup, the Kernel runs and spawns the basic processes (sched, init, bdflush, vhand).  The init processes spawns or “creates” many other processes including:  bcheckrc (check for “dirty” filesystem – runs fsck to clean)  rc2.d or rc3.c (Depending on run-level specified) – this causes many scripts (processes) to run when starting up (rc simply stands for “run control”)  getty (used to set the terminal type, speed & line discipline of terminal connection). Getty process also prompts user to enter username & password, and when entered runs the login process to validate the user, that allows the shell process to run and set up the user’s environment.

Processes Once the user has logged into their account and is running a shell, the user issues commands to spawn other processes (programs such as executable files, shell scripts, etc…) Memory is divided between Kernel Space and User Space. Processes “live” in user space which is the portion of computer memory that holds running programs and their data. In order to spawn these processes, the shell must use the fork() system call to create another process in order to run the program. The state diagram in the next slide demonstrates how new processes are spawned from the user’s shell.

Unix Process – State Diagram

Managing Processes  Managing process is similar to managing files & directories: Can set attributes of processes (niceness level) Can “hide” processes in background (ctrl-z, &, bg, fg) Can identify processes by ID # ($$) Can create and remove processes (fork, kill) Can list process information using ps command Excess number of running processes can reduce system performance (eg. Internet worms, viruses)

Managing Processes  ps command Used to display process information. By default (no arguments) will only display basic information of user’s processes. Other options: -ashow all processes connected to tty -xshow processes no connected to tty (eg. background) -eshow all processes -ffull listing -llong listing -uuser-oriented format Popular ps command combinations: ps –la ps -aux

Running Program in Same Process In shell scripting, programs can be run in same process by using exec command. In a C program, the system() call can be used (eg. system(“ls”);) but is considered inefficient because another process is created in a shell to run command. The exec system call is used to run programs or commands within the same process. There is no actual exec system call, but a series of specific exec system calls: Execl, execlp, execle, execv, execvp, execve

Running Program in Same Process  execl – requires pathname to program, # number of arguments ending with a null pointer.  execlp – need only program name (no full pathname), plus number of arguments ending with a null pointer.  execle – same as execl, but can also pass a new program environment.  execv – requires pathname to program, plus an array of strings containing arguments.  execvp – need only program name, plus an array of strings containing arguments.  exece – same as execv except can also pass a new program environment. You can view programming examples in Sigma at: ~msaul/unx511/processes

Processes  Problem with using exec:  Running exec is placed into the current process thus replacing the code and data of that process – when exec is finished, process is terminated and returned to shell prompt.  What if we want to keep code & data of current process after running exec?  Solution: Use fork to create a copy of the parent process and instruct parent process to wait until child process to complete to execute the remaining tasks. Refer to example execlp_fork.c in ~msaul/unx511/processes (try issuing execlp_fork | more - what happens?)

Processes  System Calls: fork() Creates a child process. Zero represents the child process and fork will return the PID of the child process. wait() “Blocks” the parent process until a child process finishes (i.e. parent process is blocked until a child process calls exit ). Wait will also return the value of the finished child process. waitpid() “blocks” the parent process until a specific child has finished, or run parent process without child to finish, but check on status of child process exiting.

Processes  Zombie Processes When a child process dies and calls exit, various operations are run to de-allocate memory assigned to the process, close open files, and frees all data structures. The kernel store the exit message from the child process to be used by the parent (in case it has called wait and is waiting for the child process to exit). A process that has died but has an uncollected exit value is called a zombie process. This can happen in poorly designed programs that don’t wait long enough to “mop-up” all terminated processes Refer to example x in ~msaul/unx511/signals directory

Signals A signal in terms of Unix represents an event message. Signals that are caused by a process (such as dividing by zero) are referred to as synchronous signals. Signals that are caused by events outside the process (like the user pressing CTRL C) are called asynchronous signals. Asynchronous signals go to ALL attached processes. Signals can be numbered, or assigned names (for example, signal #9 or signal name SIGKILL represents the KILL PROCESS signal)

Signals  Types: Signal Name(Signal #)  SIGABRT(6) - Process Abort (CTRL \) SIGINT(2) - Interrupt (CTRL C) SIGCHLD(20) - Child process has stopped or exited. SIGSTOP(19) - Stop executing (CTRL Z can’t be ignored ) SIGALRM(14) - Alarm Clock SIGFPE(8) - Floating Point Exception SIGHUP(1) - Hang-up SIGILL(4) - Illegal Instruction SIGKILL(9) - Kill Process (cannot be ignored) SIGPIPE(13) - Write on pipe with no reader SIGQUIT(3) - Terminal Quit SIGSEGV(11) - Invalid memory segment access SIGTERM(15) - Termination SIGUSR1(30) - User-defined Signal 1 SIGUSR2(31) - User-defined Signal 2 Issue command kill –l for a full listing or try man 7 signal for more info.

Signals – System calls  signal() Used to allow process to instruct Kernel how to respond to the signal. For example, signal(SIGINT, SIG_IGN) instructs the Kernel to ignore the interrupt signal (eg ignore CTRL C ). The first parameter is the signal, and the second parameter is the instruction. Another instruction can be SIG_DFL which means to restore the default action of the signal (like SIGINT – CTRL C would then interrupt). An instruction can also be a function name (like returning to canonical mode, etc… when pressing CTRL C).

Signals – System calls  pause() Can be used to suspend (block) execution until a specific signal occurs. For example, pause(SIGINT)  raise() Can be used to generate or “raise” a signal. For Example, raise(SIGALRM), raise(SIGKILL), etc…

Signals – System calls kill(pid,signal) Used to allow processes to terminate and send signals to other processes. Any signal can be sent via the kill command. Eg. kill(getpid(),SIGARLM), kill(getppid(),SIGTERM), etc… sigaction() A “newer” system call designed to replace “signal” system call (although most programs use “signal”). Refer (in Sigma) to ~msaul/unx511/signals directory for examples involving these system calls involving signals