Process life and death. Tuesday, September 28, 2010

Transcription

1 The_Visible_OS Page 1 Process life and death Tuesday, September 28, :50 PM So far, We've studied what a process is, and know that it has a limited view of the OS, and has one of a limited number of states. In this lecture, We'll explore a process's world in linux, how a process is born and dies, and how it requests services from the operating system.

2 System calls Wednesday, September 13, :26 PM You're used to running programs in "the shell" (bash or tcsh). In this lecture, we will learn how to run a program from inside a C program. This does exactly what the shell does. This is done via system calls. The_Visible_OS Page 2

3 The_Visible_OS Page 3 Creating a process Thursday, September 23, :10 PM Two steps From file.c to a.out from a.out to running image

4 From file.c to a.out Thursday, September 23, :09 PM The_Visible_OS Page 4

5 My program Tuesday, September 25, :44 PM #include <stdio.h> main() { printf("hi there\n"); } You can see the contents of file.o with the command nm. The_Visible_OS Page 5

6 The_Visible_OS Page 6 From a.out to running image Thursday, September 23, :13 PM file.o contains external symbols and defined symbols libc.a contains.o files for all library functions. Process of linking: scan libc.a for symbols declared external by file.o, load appropriate.o files. A window into libc.a: "ar" ar t /usr/lib/libc.a # lists all the.o files in libc.a A window into linking: "nm" nm file.o # lists the file's symbol table.

7 ld.so: the dynamic linker Thursday, September 23, :13 PM This is a memory saving device The_Visible_OS Page 7

8 The_Visible_OS Page 8 Notes Wednesday, September 13, :52 PM ld is the static linker: turns an object file into a program. ld.so is the dynamic linker: turns an a.out into a process.

9 The concept of sharing Tuesday, September 27, :41 PM q The_Visible_OS Page 9

10 The_Visible_OS Page 10 The concept of sharing Wednesday, September 13, :53 PM The purpose of ld.so is to allow programs to share things that don't change. Example: the text segment is read-only, so it is shared among all instances of a program.

11 The_Visible_OS Page 11 Executing a process Thursday, September 23, :13 PM When you try to run a process: fork(2) creates a copy of the current process (your shell) exec(2) replaces that copy with the new process: run ld.so to load process into memory. Load a.out followed by libc.so (and perhaps other dynamic libraries) Link external symbols in a.out to defined symbols in libc.so Start execution of new process.

12 The_Visible_OS Page 12 Shared memory Thursday, September 23, :00 PM The.so file is a shared object Same format as an object file (.o) Designed to be shared between processes. Only one copy for all processes, in memory!

13 The_Visible_OS Page 13 Designing for shared memory Thursday, September 23, :00 PM Calling printf loads printf.o in libc.a, which is a stub that just calls the printf shared code in libc.so. so that your program only has to load a tiny subroutine in order to access the shared space!

14 Picture of the whole process Wednesday, September 13, :02 PM The_Visible_OS Page 14

15 The_Visible_OS Page 15 Process sharing behavior Thursday, September 22, :41 PM Process sharing behavior Program is in the text segment Read-only Shared among every running instance of the program Data is in the stack, heap, global segments. Read-write Not shared. If 100 students are running emacs, there is one copy of its text segment!

16 The_Visible_OS Page 16 Copy on write Tuesday, September 25, :00 PM Copy on write When a read/write page is copied, it isn't actually copied until some process writes to it. It's made read only so write to it will generate an interrupt(!) The first process that writes to a copy-onwrite page Generates an interrupt Copies the page, makes both copies r/w Resumes execution

17 The_Visible_OS Page 17 "DLL Hell" Thursday, September 22, :58 PM This has behavioral ramifications Every Microsoft application comes with its own DLLs (Dynamically Linked Libraries, Microsoft's version of.so's) One application can overwrite the DLLs of another. Result: execution errors! Exact same problem with.so's in linux. But: my students have verified that -- at least -- RedHat has its act together.

18 The_Visible_OS Page 18 Process life and death Monday, September 18, :39 PM Process life and death Every process other than the first one (init, process with process-id=1) is the child of some other process (that called fork(2) to create it). Every process reports its exit code to its parent, who must "reap" that code. If a parent is remiss in reading the code, a process becomes a zombie, i.e., the living dead. Zombie processes can clutter a process table and bring a system to its knees.

19 The_Visible_OS Page 19 Process creation Monday, September 18, :39 PM Demystifying process creation and destruction: three important system calls: fork(), exec(), and wait(). fork(): make an identical copy of the current process. exec(): replace the current process with another one, specified via exec's arguments. wait(): wait for a child process to complete and reaps its exit code.

20 The_Visible_OS Page 20 Creation examples Friday, September 23, :58 AM Example: running a "cat" command in the foreground: Example: running a "cat" command in the foreground with explicit wait: Example: running a "cat" command in the background with implicit wait: Example: running a user-typed command in the foreground without arguments: Example: running a user-typed command in the background without arguments:

21 The_Visible_OS Page 21 Picture of first example Monday, September 22, :32 PM

22 The_Visible_OS Page 22 The point Tuesday, September 27, :06 PM The point of this discussion: typing./a.out in the shell is an explicit wait. typing./a.out & in the shell is a background execution. The difference is which system calls are called when.

23 The_Visible_OS Page 23 Caveats about waiting Friday, September 23, :59 AM General caveats about waiting if parent dies, parent doesn't have to wait. Children become children of the system process init, which reaps them when they die. if parent doesn't call wait or reap, child becomes a zombie until it does. Thus it is quite easy to make a host a "city of the living dead": while (1) { if (!fork()) { exit(0); } } The process spawns an unlimited number of children, each of which immediately dies and becomes a zombie, because the parent is still running and hasn't "wait"ed for the child's status! Compare this with while (1) { if (!fork()) { exit(0); } // child dies else { wait(&status); } // parent reaps } which works correctly (if uselessly).

24 The_Visible_OS Page 24 What exactly happens during a fork()? Friday, September 23, :00 AM What exactly happens during a fork()? The whole running program gets copied, including its environment. all open files. Both copies then proceed to execute independently. The parent gets the pid of the child from fork(). The child gets a 0 (indicating that it is not a parent to anything).

25 The_Visible_OS Page 25 What happens during an exec? Friday, September 23, :04 AM What happens during an exec? Environment is preserved. Open files stay open. All of memory is replaced. File buffers are silently lost. In particular: File buffers are not flushed. The buffers themselves are erased! Buffered writes can be lost.

26 The_Visible_OS Page 26 What is the purpose of a wait? Friday, September 23, :07 AM What is the purpose of a wait? When a process dies, it stores an exit code (an integer). 0 means a normal exit. non-zero exit codes represent errors. You set that code with the exit system call: exit(1); // error exit wait's purpose is to read that code (in the parent).

27 The_Visible_OS Page 27 Strange fork behavior Tuesday, September 27, :16 PM E.g., consider the following: main() { printf("this will get printed ") if (fork()) { printf("...eventually\n"); } else { printf("...twice\n"); } } This prints something like: this will get printed...eventually\n this will get printed...twice\n because the first printf buffers the write before the fork. Question: in which order?

28 The_Visible_OS Page 28 Strange execl behavior Tuesday, September 27, :19 PM E.g., consider the following main() { printf("this won't get seen at all "); execl("/bin/cat", "cat", "/dev/null", 0); } // prints nothing at all, because // the execl erases the unwritten line buffer!

29 The_Visible_OS Page 29 End of lecture on 9/13/2017 Wednesday, September 13, :32 PM

30 The_Visible_OS Page 30 Aspects of the execution environment Monday, September 18, :12 PM Aspects of execution environment environment variables: specify user preferences resource limits: specify what a process can or cannot do. i/o: which files are open? Caveat: when a process forks, its environment is copied exactly into its child.

31 The_Visible_OS Page 31 During execution Friday, September 23, :11 AM During execution, A process can open and close files. (and -- implicitly -- make those open files available to children) open, close: unbuffered open and close of a file. fopen, fclose: buffered open and close of a file. A process can read and change its own environment (and -- implicitly -- the environments of its children!) getenv: read an environment variable. setenv: change an environment variable (for children) A process can limit its own behavior (and -- implicitly -- that of its children)

32 The_Visible_OS Page 32 Environment Monday, September 18, :12 PM Purpose of environment variables: inform programs of defaults: Example: PRINTER In TCSH: lp file # prints to default printer. setenv PRINTER hp231 lp file # prints to printer outside my office

33 The_Visible_OS Page 33 getenv and setenv Friday, September 23, :58 AM getenv and setenv Can set environment variables These are present in the child after a fork() They remain present after an exec()!

34 Limiting behaviors Wednesday, September 20, :03 PM Limiting process behaviors getrlimit, setrlimit: make processes "behave" struct rlimit { rlim_t rlim_cur; /* Soft limit */ rlim_t rlim_max; /* Hard limit */ }; int getrlimit(int kind, struct rlimit *limits); int setrlimit(int kind, const struct rlimit *limits); Kinds of limits RLIMIT_CPU: CPU time utilized RLIMIT_DATA: size of data segments RLIMIT_FSIZE: max size of files created by process RLIMIT_LOCKS: number of advisory file locks used RLIMIT_MEMLOCK: size of memory prevented from swapping out RLIMIT_NOFILE: number of files that can be open. RLIMIT_NPROC: number of processes created. RLIMIT_RSS: size of resident memory set. RLIMIT_STACK: stack size Kinds of limits: soft limits inform the process that it's over bounds, but do not stop it. hard limits terminate the process. Note: a normal process can only make its limits more restrictive. The_Visible_OS Page 34

35 It cannot remove a limit! See The_Visible_OS Page 35

36 The_Visible_OS Page 36 Why would you want to limit yourself? Friday, September 23, :25 AM Why would you want to limit yourself? Protect the system from potential errors. Limit child behavior. E.g. if (fork()) { // parent wait... } else { // child setrlimit // limit the child ONLY exec // do something potentially unsafe }

37 The_Visible_OS Page 37 What can the process see? Friday, September 23, :27 AM What can the process see? Resource utilization. Operating system status.

38 Resource monitoring Wednesday, September 20, :38 PM Resource monitoring make processes aware of information about themselves and the operating system allow intelligent decision-making on the part of processes struct rusage { struct timeval ru_utime; /* user time used */ struct timeval ru_stime; /* system time used */ long ru_maxrss;/* maximum resident set size */ long ru_ixrss;/* integral shared memory size */ long ru_idrss;/* integral unshared data size */ long ru_isrss;/* integral unshared stack size */ long ru_minflt;/* page reclaims */ long ru_majflt;/* page faults */ long ru_nswap;/* swaps */ long ru_inblock;/* block input operations */ long ru_oublock;/* block output operations */ long ru_msgsnd;/* messages sent */ long ru_msgrcv; /* messages received */ long ru_nsignals; /* signals received */ long ru_nvcsw; /* voluntary context switches */ long ru_nivcsw; /* involuntary context switches */ }; struct rusage r; getrusage(rusage_self, &r); // fetch data for self: man 2 getrusage getrusage(rusage_children, &r); // fetch data for children See The_Visible_OS Page 38

39 The_Visible_OS Page 39 Watch out! Friday, September 23, :23 AM Watch out! Not all resources are actually monitored! Some are only updated on process exit! Some are only updated on child reap!