One of the most profound ideas in computer science Not the same as program or processor

Similar documents
Dept. of Computer Science & Engineering 1 Knowledge & Data Engineering Lab.

Parents and Children

Lesson 2. process id = 1000 text data i = 5 pid = 1200

Operating systems and concurrency - B03

Ricardo Rocha. Department of Computer Science Faculty of Sciences University of Porto

CSC209 Fall Karen Reid 1

Unix Processes 1 / 31

System Programming. Process Control II

CSC 252: Computer Organization Spring 2018: Lecture 19

CS240: Programming in C

OS Lab Tutorial 1. Spawning processes Shared memory

PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of Information Sciences and Engineering

CSC 1600 Unix Processes. Goals of This Lecture

CS 355 Operating Systems. Keeping Track of Processes. When are processes created? Process States 1/26/18. Processes, Unix Processes and System Calls

Processes. Operating System CS 217. Supports virtual machines. Provides services: User Process. User Process. OS Kernel. Hardware

Unix-Linux 2. Unix is supposed to leave room in the process table for a superuser process that could be used to kill errant processes.

CSci 4061 Introduction to Operating Systems. Processes in C/Unix

Operating Systems. Lecture 05

Preview. Process Control. What is process? Process identifier The fork() System Call File Sharing Race Condition. COSC350 System Software, Fall

Operating System Structure

COMP 2355 Introduction to Systems Programming

CPSC 341 OS & Networks. Processes. Dr. Yingwu Zhu

Processes. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University

Processes. Today. Next Time. ! Process concept! Process model! Implementing processes! Multiprocessing once again. ! Scheduling processes

UNIX System Calls. Sys Calls versus Library Func

Process Management! Goals of this Lecture!

Lecture 5. Systems Programming: Unix Processes Creation: fork & exec Process Communication: Pipes

Process Management 1

PROCESS CONTROL BLOCK TWO-STATE MODEL (CONT D)

Exceptional Control Flow Part I

fork System-Level Function

CS240: Programming in C

Processes. CSE 351 Autumn Instructor: Justin Hsia

System Programming. Introduction to Unix

Process management 1

CSC209H Lecture 6. Dan Zingaro. February 11, 2015

System Programming. Process Control III

Princeton University Computer Science 217: Introduction to Programming Systems. Process Management

Princeton University Computer Science 217: Introduction to Programming Systems. Process Management

What is a Process. Preview. What is a Process. What is a Process. Process Instruction Cycle. Process Instruction Cycle 3/14/2018.

Announcement (1) sys.skku.edu is now available

Princeton University. Computer Science 217: Introduction to Programming Systems. Process Management

Process Management! Goals of this Lecture!

Processes: Introduction. CS 241 February 13, 2012

CS24: INTRODUCTION TO COMPUTING SYSTEMS. Spring 2017 Lecture 19

CS24: INTRODUCTION TO COMPUTING SYSTEMS. Spring 2018 Lecture 20

CS 201. Processes. Gerson Robboy Portland State University

Processes & Threads. Today. Next Time. ! Process concept! Process model! Implementing processes! Multiprocessing once again. ! More of the same J

Processes. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University

Process Creation in UNIX

PROCESSES. Jo, Heeseung

Processes. Jo, Heeseung

Processes. CSE 351 Autumn Instructor: Justin Hsia

CS631 - Advanced Programming in the UNIX Environment. Process Environment, Process Control

Exceptions and Processes

518 Lecture Notes Week 3

Process Management 1

UNIX Processes. by Armin R. Mikler. 1: Introduction

Control Flow. Systemprogrammering 2007 Föreläsning 2 Exceptional Control Flow Part I. Exceptional Control Flow. Altering the Control Flow

System Calls. Library Functions Vs. System Calls. Library Functions Vs. System Calls

Giving credit where credit is due

Windows architecture. user. mode. Env. subsystems. Executive. Device drivers Kernel. kernel. mode HAL. Hardware. Process B. Process C.

Exceptional Control Flow Part I Oct. 17, 2002

PROCESS MANAGEMENT. Operating Systems 2015 Spring by Euiseong Seo

Carnegie Mellon. Processes. Lecture 12, May 19 th Alexandre David. Credits to Randy Bryant & Dave O Hallaron from Carnegie Mellon

Fall 2015 COMP Operating Systems. Lab #3

Programmation Systèmes Cours 2 Process Management

Interprocess Communication E. Im

Processes. q Process concept q Process model and implementation q Multiprocessing once again q Next Time: Scheduling

Week 2 Intro to the Shell with Fork, Exec, Wait. Sarah Diesburg Operating Systems CS 3430

Exceptional Control Flow Part I

OS Interaction and Processes

Q & A (1) Where were string literals stored? Virtual Address. SSE2033: System Software Experiment 2 Spring 2016 Jin-Soo Kim

University of Washington What is a process?

Are branches/calls the only way we can get the processor to go somewhere in a program? What is a program? A processor? A process?

Introduction to Processes

This document gives a general overview of the work done by an operating system and gives specific examples from UNIX.

Exceptional Control Flow: Exceptions and Processes

Processes. Today. Next Time. Process concept Process model Implementing processes Multiprocessing once again. Scheduling processes

CS 33. Architecture and the OS. CS33 Intro to Computer Systems XIX 1 Copyright 2017 Thomas W. Doeppner. All rights reserved.

Kernel and processes

Exceptional Control Flow Part I September 22, 2008

CS 33. Architecture and the OS. CS33 Intro to Computer Systems XIX 1 Copyright 2018 Thomas W. Doeppner. All rights reserved.

Altering the Control Flow

Today. Exceptional Control Flow Processes. Exceptions and Processes. Control Flow. Altering the Control Flow

Process management. What s in a process? What is a process? The OS s process namespace. A process s address space (idealized)

CSE 153 Design of Operating Systems Fall 2018

OS lpr. www. nfsd gcc emacs ls 1/27/09. Process Management. CS 537 Lecture 3: Processes. Example OS in operation. Why Processes? Simplicity + Speed

EXPERIMENT NO : M/C Lenovo Think center M700 Ci3,6100,6th Gen. H81, 4GB RAM,500GB HDD

Operating Systems. II. Processes

CS631 - Advanced Programming in the UNIX Environment. Process Environment, Process Control

Processes, Exceptional

CSE 451: Operating Systems Winter Module 4 Processes. Mark Zbikowski Allen Center 476

Overview. Unix System Programming. What is a Process? Outline. What is a Process? What is a Process?

Discussion of Assignments 2. Line buffered vs. full buffered I/O. Some often encountered issues in the submissions.

CS 261 Fall Mike Lam, Professor. Exceptional Control Flow and Processes

Operating Systems. Processes

CSE 410: Computer Systems Spring Processes. John Zahorjan Allen Center 534

Today. Introduction to Computer Systems /18 243, Fall th Lecture. Control Flow. Altering the Control Flow.

Altering the Control Flow

Transcription:

Process Control 1

Carnegie Mellon Processes Definition: A process is an instance of a running program. One of the most profound ideas in computer science Not the same as program or processor Process provides each program with two key abstractions: Logical control flow Each program seems to have exclusive use of the CPU Provided by kernel mechanism called context switching Private address space Each program seems to have exclusive use of main memory. Provided by kernel mechanism called virtual memory and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition Memory Stack Heap Data Code CPU Registers 2

Multiprocessing: The Illusion Memory Memory Memory Carnegie Mellon Stack Heap Data Code Stack Heap Data Code Stack Heap Data Code CPU Registers CPU Registers CPU Registers Computer runs many processes simultaneously Applications for one or more users Web browsers, email clients, editors, Background tasks Monitoring network & I/O devices and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 3

Carnegie Mellon Multiprocessing Example Running program top on Mac System has 123 processes, 5 of which are active Identified by Process ID (PID) and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 4

Multiprocessing: The (Traditional) Reality Memory Carnegie Mellon Stack Heap Data Code Stack Heap Data Code Stack Heap Data Code Saved registers Saved registers Saved registers CPU Registers Single processor executes multiple processes concurrently Process executions interleaved (multitasking) Address spaces managed by virtual memory system (later in course) Register values for nonexecuting processes saved in memory and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 5

Multiprocessing: The (Traditional) Reality Memory Carnegie Mellon Stack Heap Data Code Stack Heap Data Code Stack Heap Data Code Saved registers Saved registers Saved registers CPU Registers Save current registers in memory and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 6

Multiprocessing: The (Traditional) Reality Memory Carnegie Mellon Stack Heap Data Code Stack Heap Data Code Stack Heap Data Code Saved registers Saved registers Saved registers CPU Registers Load saved registers and switch address space (context switch) and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 7

Multiprocessing: The (Modern) Reality Memory Carnegie Mellon Stack Heap Data Code Stack Heap Data Code Stack Heap Data Code Saved registers Saved registers Saved registers CPU Registers CPU Registers and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition Multicore processors Multiple CPUs on single chip Share main memory (and some of the caches) Each can execute a separate process Scheduling of processors onto cores done by kernel 8

Carnegie Mellon Concurrent Processes Each process is a logical control flow. Two processes run concurrently (are concurrent) if their flows overlap in time Otherwise, they are sequential Examples (running on single core): Concurrent: A & B, A & C Sequential: B & C Process A Process B Process C Tim e and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 9

Carnegie Mellon User View of Concurrent Processes Control flows for concurrent processes are physically disjoint in time However, we can think of concurrent processes as running in parallel with each other Process A Process B Process C Time and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 10

Carnegie Mellon Context Switching Processes are managed by a shared chunk of memory-resident OS code called the kernel Important: the kernel is not a separate process, but rather runs as part of some existing process. Control flow passes from one process to another via a context switch Process A Process B Time user code kernel code user code kernel code user code context switch context switch and O Hallaron, Computer Systems: A Programmer s Perspective, Third Edition 11

Process Control 12

Process Control Process control process creation, program execution, and process termination Process properties real, effective, and saved; user and group IDs Interpreter files and the system function Process accounting

Process Identifiers #include <unistd.h> pid_t getpid(void); pid_t getppid(void); // get parent's pid uid_t getuid(void); uid_t geteuid(void); // get effective userid gid_t getgid(void); gid_t getegid(void); Process ID: a unique, non-negative integer

Process Identifiers Process ID 0 The scheduler process Process ID 1 The init process invoked by the kernel at the end of the bootstrap procedure /sbin/init It reads the system-dependent initialization files (i.e., /et c/rc*) and brings a Unix system to a certain state. ((/etc/inittab and /etc/init.d/) or /etc/rc*) Process ID 2 pagedaemon responsible for supporting the paging of the virtual memory system.

fork Function #include <unistd.h> pid_t fork(void); This function is called once, but returns twice. returns 0 in the child, returns the process ID of the new child in the parent. The child is a copy of the parent (data space, hea p, and stack). Often, text segment is shared. Copy-on-write (COW)

#include "apue.h" int glob = 6; /* external variable in initialized data */ char buf[] = "a write to stdout\n"; int main(void) { int var; /* automatic variable on the stack */ pid_t pid; var = 88; if (write(stdout_fileno, buf, sizeof(buf)-1)!= sizeof(buf)-1) err_sys("write error"); printf("before fork\n"); /* we don't flush stdout */ if ((pid = fork()) < 0) { err_sys("fork error"); } else if (pid == 0) { glob++; /* modify variables */ var++; } else { sleep(2); } printf("pid = %d, glob = %d, var = %d\n", getpid(), glob, var); exit(0); } Figure 8.1

fork Function Figure 8.1 $./a.out a write to stdout before fork pid = 430, glob = 7, var = 89 pid = 429, glob = 6, var = 88

fork Function parent process table entry fd flags ptr fd 0: fd 1: fd 2: file table file status flags current file offset v-node ptr file status flags current file offset v-node ptr v-node table v-node information i-node information current file size v-node information i-node information current file size file status flags current file offset v-node ptr v-node information i-node information current file size All descriptors that are open in the parent are dupli cated in the child.

fork Function parent process table entry fd flags ptr fd 0: fd 1: fd 2: child process table entry file table file status flags current file offset v-node ptr file status flags current file offset v-node ptr v-node table v-node information i-node information current file size v-node information i-node information current file size fd flags ptr fd 0: fd 1: fd 2: file status flags current file offset v-node ptr v-node information i-node information current file size All descriptors that are open in the parent are duplicated in the child.

fork Function Two normal cases for handling descriptors after a fork The parent waits for the child to complete. When the child terminates, any of shared descriptors read/writte n by the child will have their file offsets updated accor dingly. The parent and child each go their own way. After fo rk, they close the descriptors that they don t need.

user s perspective (virtual memory)

fork Function Properties inherited by the child real UID/GID, effective UID/GID, supplementary GIDs process group ID session ID controlling terminal set-user-id flag and set-group-id flag current working directory root directory file mode creation mask signal mask and dispositions the close-on-exec flag for any open file descriptors environment attached shared memory segments memory mapping resource limits

fork Function Differences between the parent and child the return value from fork the process IDs, parent process IDs the child s values for tms_utime, tms_stime, tms_cutime, and tms_cstime are set to 0 file locks set by the parent are not inherited by the chil d pending alarms are cleared for the child the set of pending signals for the child is set to the em pty set

fork Function Two reasons for fork to fail Too many processes in the system CHILD_MAX: the total number of processes per real user ID Two uses for fork The parent and child execute different sections of code at the same time, e.g. network servers. The parent and child execute a different progra m, e.g. shells (the child does an exec right after returning from the fork.)

vfork Function vfork does not fully copy the address space of th e parent into the child (since the child won t reference that address space the child just calls exec or exit.) The child runs in the parent address space. vfork guarantees that the child runs first, until th e child calls exec or exit. Figure 8.3 _exit vs. exit (flushing and closing stdout) $ a.out before vfork pid = 29039, glob = 7, var = 89

#include "apue.h" int glob = 6; /* external variable in initialized data */ int main(void) { int var; /* automatic variable on the stack */ pid_t pid; var = 88; printf("before vfork\n"); /* we don't flush stdio */ if ((pid = vfork()) < 0) { err_sys("vfork error"); } else if (pid == 0) { /* child */ glob++; /* modify parent's variables */ var++; _exit(0); /* child terminates */ } /* Parent continues here.*/ printf("pid = %d, glob = %d, var = %d\n", getpid(), glob, var); exit(0); } Figure 8.3

wait and waitpid Function When a process terminates, the parent is notified by the kernel via the SIGCHLD signal. #include <sys/wait.h> pid_t wait(int *statloc); pid_t waitpid(pid_t pid, int *statloc, int options); wait can block the caller until a child terminates, while waitpid has an option that prevents it from blocking. If a child is a zombie, wait immediately returns that chil d s process ID with its termination status. Otherwise, it b locks the caller until a child terminates. waitpid can wait for a specific process.

wait and waitpid Function Macros to examine termination status WIFEXITED(status): normal termination WEXITSTATUS(status) WIFSIGNALED(status) : terminated by a signal WTERMSIG(status) WCOREDUMP(status) WIFSTOPPED(status): currently stopped WSTOPSIG(status) WIFCONTINUED(status): continued after a job control sto p Figure 8.5 and Figure 8.6

#include "apue.h" #include <sys/wait.h> void pr_exit(int status) { if (WIFEXITED(status)) printf("normal termination, exit status = %d\n", WEXITSTATUS(status)); else if (WIFSIGNALED(status)) printf("abnormal termination, signal number=%d%s\n", WTERMSIG(status), #ifdef WCOREDUMP WCOREDUMP(status)? " (core file generated)" : ""); #else ""); #endif else if (WIFSTOPPED(status)) printf("child stopped, signal number = %d\n", WSTOPSIG(status)); } Figure 8.5

wait and waitpid Function #include "apue.h" #include <sys/wait.h> int main(void) { pid_t pid; int status; if ((pid = fork()) < 0) err_sys("fork error"); else if (pid == 0) /* child */ exit(7); if (wait(&status)!= pid) /* wait for child */ err_sys("wait error"); pr_exit(status); /* and print its status */ if ((pid = fork()) < 0) err_sys("fork error"); else if (pid == 0) /* child */ status /= 0; /* divide by 0 generates SIGFPE */ if (wait(&status)!= pid) /* wait for child */ err_sys("wait error"); pr_exit(status); /* and print its status */ exit(0); } Figure 8.6 if ((pid = fork()) < 0) err_sys("fork error"); else if (pid == 0) /* child */ abort(); /* generates SIGABRT */ if (wait(&status)!= pid) /* wait for child */ err_sys("wait error"); pr_exit(status); /* and print its status */

wait and waitpid Function pid_t waitpid(pid_t pid, int *statloc, int options); pid pid == -1 waits for any child process. pid > 0 waits for the child whose process ID equals pid. pid == 0 waits for any child whose process group ID equals that of the calling process. pid < -1 waits for any child whose process group ID equals the a bsolute value of pid. options WCONTINUED the status of any child continued is returned. WNOHANG waitpid will not block (returns 0). WUNTRACED the status of any child stopped is returned. Figure 8.8

wait and waitpid Function #include "apue.h" #include <sys/wait.h> int main(void) { pid_t pid; if ((pid = fork()) < 0) { err_sys("fork error"); } else if (pid == 0) { /* first child */ if ((pid = fork()) < 0) err_sys("fork error"); else if (pid > 0) exit(0); /* parent from second fork == first child */ /* * We're the second child; our parent becomes init as soon * as our real parent calls exit() in the statement above. * Here's where we'd continue executing, knowing that when * we're done, init will reap our status. */ sleep(2); printf("second child, parent pid = %d\n", getppid()); exit(0); } */ if (waitpid(pid, NULL, 0)!= pid) /* wait for first child err_sys("waitpid error"); /* * We're the parent (the original process); * we continue executing, * knowing that we're not the parent of * the second child. */ exit(0); } Figure 8.8

wait3 and wait4 Functions #include <sys/types.h> #include <sys/wait.h> #include <sys/time.h> #include <sys/resource.h> pid_t wait3(int *statloc, int options, struct rusage *rusage); pid_t wait4(pid_t pid, int *statloc, int options, struct rusage *ruage); It returns a summary of the resources used by the t erminated process and all its child processes. User/system CPU time, number of page faults, number of signals received, and the like

exec Functions #include <unistd.h> int execl(const char *pathname, const char *arg0, /* (char *) 0 */); int execv(const char *pathname, char *const argv[]); int execle(const char *pathname, const char *arg0, /* (char *) 0, char *const envp[] */); int execve(const char *pathname, char *const argv[], char *const envp[]); int execlp(const char *filename, const char *arg0, /* (char *) 0 */) int execvp(const char *filename, char *const argv[]); exec merely replaces the current process (its text, data, heap, and stack segments) with a brand new program from disk. l list of arguments, v argv[] vector, e an envp [] array, and p a filename argument.

exec Functions Filename argument (execlp/execvp) If filename contains a slash, it is taken as a pathname. Otherwise, the executable is searched for in PATH environ ment variable directories. If not a machine executable, it invokes /bin/sh with the filename as input to the shell. Argument passing execl/execlp/execle require separate command-line arguments with the end of the arguments marked with a null pointer. Environment list passing execle/execve passing const *char envp[] instead of using extern char **environ

exec Functions Properties inherited from the calling process pid, ppid, real UID/GID, supplementary GIDs process group ID, session ID controlling terminal time left until alarm clock current working directory, root directory file mode creation mask, file locks process signal mask, pending signals resource limits tms_utime, tms_stime, tms_cutime, and tms_cstime Handling of open files the close-on-exec flag of every open descriptor: if set, the descriptor is closed across an exec. FD_CLOEXEC flag Effective UID/GID can change, depending on the status of the set-user-id and the set-group-id bits for the progra m file.

exec Functions #include "apue.h" #include <sys/wait.h> char *env_init[] = { "USER=unknown", "PATH=/tmp", NULL }; int main(void) { pid_t pid; if ((pid = fork()) < 0) { err_sys("fork error"); } else if (pid == 0) { /* specify pathname, specify environment */ if (execle("/home/sar/bin/echoall", "echoall", "myarg1", "MY ARG2", (char *)0, env_init) < 0) err_sys("execle error"); } Figure 8.16

if (waitpid(pid, NULL, 0) < 0) err_sys("wait error"); if ((pid = fork()) < 0) { err_sys("fork error"); } else if (pid == 0) { /* specify filename, inherit environment */ if (execlp("echoall", "echoall", "only 1 arg", (char *)0) < 0) err_sys("execlp error"); } exit(0); }

Changing User IDs and Group IDs #include <unistd.h> int setuid(uid_t uid); int setgid(gid_t gid); A superuser process can set the real UID, effective UID, and saved set-user-id to uid. If uid equals either the real UID or the saved set-use r-id, setuid sets only the effective UID to uid. Otherwise, errno is set to EPERM.

Changing User IDs and Group IDs exec setuid(uid) ID set-user-id bit of set-user-id bit on superuser unprivileged user real user ID efective user ID saved set-user ID unchanged unchanged copied from ef - fective user ID unchanged set from user ID of program file copied from efective user ID set to uid set to uid set to uid unchanged set to uid unchanged Only a superuser process can change the real user ID. The effective UID is set by the exec function, only if the set-user-id bit is set f or the program file. We can call setuid at any time to set the effective UID t o either the real UID or the saved set-user-id. The saved set-user-id is copied from the effective UID by exec.

Changing User IDs and Group IDs saved set-user-id feature Assuming that the man program file is owned by the user name man and has its set-user-id bit set 1. When we exec it, 2. real user ID = our user ID 3. effective user ID = man 4. saved set-user-id = man 5. The man program accesses the required configuration files and m anual pages (owned by the user name man.) 6. Before man runs any command on our behalf, it calls setuid(ge tuid()) to safely execute filter programs. 7. real user ID = our user ID (unchanged) 8. effective user ID = our user ID 9. saved set-user-id = man (unchanged)

Changing User IDs and Group IDs 4. When the filter is done, man calls setuid(mane uid). This call is allowed because maneuid equa ls the saved set-user-id. 5. real user ID = our user ID (unchanged) 6. effective user ID = man 7. saved set-user-id = man (unchanged) 5. The man program can now operate on its files, as its effective UID is man. Extra privileges at the beginning and end, but our normal privilege most of the time.

Changing User IDs and Group IDs #include <unistd.h> int setreuid(uid_t ruid, uid_t euid); int setregid(gid_t rgid, gid_t egid); Swapping of the real UID and the effective UID Either the real UID can be set to the effective UID, or th e effective UID can either be set to the saved set-user I D or the real UID. #include <unistd.h> int seteuid(uid_t uid); int setegid(gid_t gid); The effective UID can be set to either the real UID or the saved set-user-id. For a privileged user, only the effective UID is set to uid.

Changing User IDs and Group IDs superuser setreuid(ruid, euid) superuser setuid(uid) superuser seteuid(uid) ruid euid uid uid uid uid real user ID unprivileged setreuid efective user ID unprivileged setreuid saved set-user-id exec of set-user-id unprivileged setuid or seteuid unprivileged setuid or seteuid

#include "apue.h" #include <sys/wait.h> int main(void) { pid_t pid; if ((pid = fork()) < 0) { err_sys("fork error"); } else if (pid == 0) { /* child */ if (execl("/home/sar/bin/testinterp", "testinterp", "myarg1", "MY ARG2", (char *)0) < 0) err_sys("execl error"); } if (waitpid(pid, NULL, 0) < 0) /* parent */ err_sys("waitpid error"); exit(0); } Figure 8.20

Interpreter Files Interpreter files #! pathname [optional-argument] The actual file got execed by the kernel is the file specifie d by the pathname on the first line. Interpreter file vs. interpreter Figure 8.20 $ cat /home/sar/bin/testinterp #!/home/sar/bin/echarg foo $./a.out argv[0]: /home/sar/bin/echoarg argv[1]: foo argv[2]: /home/sar/bin/testinterp argv[3]: myarg1 argv[4]: MY ARGS2

system Function #include <stdlib.h> int system(const char *cmdstring); An interface to a shell (not to OS) Implemented by calling fork, exec, and waitpid Three different types of return values If either the fork fails or waitpid returns an error other tha n EINTR, -1 with errno set to indicate the error. If the exec fails, the return value is as if the shell had execut ed exit(127). Otherwise, the return value from system is the termination s tatus of the shell. Figure 8.22 & Figure 8.23

system Function #include <sys/wait.h> #include <errno.h> #include <unistd.h> int system(const char *cmdstring) /* version without signal handling */ { pid_t pid; int status; if (cmdstring == NULL) return(1); /* always a command processor with UNIX */ if ((pid = fork()) < 0) { status = -1; /* probably out of processes */ } else if (pid == 0) { /* child */ execl("/bin/sh", "sh", "-c", cmdstring, (char *)0); _exit(127); /* execl error */ } else { /* parent */ while (waitpid(pid, &status, 0) < 0) { if (errno!= EINTR) { status = -1; /* error other than EINTR from waitpid() */ break; } } } return(status); } Figure 8.22

system Function #include "apue.h" #include <sys/wait.h> int main(void) { int status; if ((status = system("date")) < 0) err_sys("system() error"); pr_exit(status); if ((status = system("nosuchcommand")) < 0) err_sys("system() error"); pr_exit(status); if ((status = system("who; exit 44")) < 0) err_sys("system() error"); } pr_exit(status); exit(0); Figure 8.23

system Function An advantage over fork and exec, is that system does all the required error/signal ha ndling. A security hole if we call system from a setuser-id program Figure 8.24 & 8.25 on page 249 A program with set-user-id or set-group-id shou ld use fork and exec directly, being certain to c hange back to normal permission after the for k, before calling exec. (no system with setuid/setgid programs)

system Function #include "apue.h" int main(int argc, char *argv[]) { int status; if (argc < 2) err_quit("command-line argument required"); if ((status = system(argv[1])) < 0) err_sys("system() error"); } pr_exit(status); exit(0); Figure 8.24 #include "apue.h" int main(void) { printf("real uid = %d, effective uid = %d\n", getuid(), geteuid()); exit(0); } Figure 8.25 $ tsys printuids normal execution, no special privileges real uid = 205, effective uid = 205 normal termination, exit status = 0 $ su become superuser Password: enter superuser password # chown root tsys change owner # chmod u+s tsys make set-user-id # ls -l tsys verify file's permissions and owner -rwsrwxr-x 1 root 16361 Mar 16 16:59 tsys # exit leave superuser shell $ tsys printuids real uid = 205, effective uid = 0 oops, this is a security hole normal termination, exit status = 0

Process Accounting Accounting records Typically a small amount of binary data with command name, system/user CPU time, UID, GID, starting/elapsed time, memory usage, termination status, read/write bytes, etc. (struct acct in <sys/acct.h>) Accounting data are all kept by the kernel in the process table (initialized whenever a new process is created.) Each accounting record is written into the account file (/var/adm/pacct on Solaris) when the process terminates.

User Identification Does getpwuid(getuid()) enable us to find out the login name of the user running the program? What if a single user has multiple login names? (i.e. multi ple entries in the password file with the same user ID) Environment variable LOGNAME What if a user modifies the environment variable? #include <unistd.h> char *getlogin(void); It returns a pointer to a login name string. It can fail if the process is not attached to a termina l that a user logged into, i.e. daemon processes.

Process Times #include <sys/times.h> clock_t times(struct tms *buf); struct tms { } clock_t tms_utime; /* user CPU time */ clock_t tms_stime; /* system CPU time */ clock_t tms_cutime; /* user CPU time, terminated children */ clock_t tms_cstime; /* system CPU time, terminated children */ It returns the elapsed wall clock time from some arbitrary poi nt in the past. The clock_t values / sysconf(_sc_clk_tck) Figure 8.30

Process Times #include "apue.h" #include <sys/times.h> static void pr_times(clock_t, struct tms *, struct tms *); static void do_cmd(char *); int main(int argc, char *argv[]) { int i; setbuf(stdout, NULL); for (i = 1; i < argc; i++) do_cmd(argv[i]); /* once for each command-line arg */ exit(0); } static void do_cmd(char *cmd) /* execute and time the "cmd" */ { struct tms tmsstart, tmsend; clock_t start, end; int status; } if ((status = system(cmd)) < 0) /* execute command */ err_sys("system() error"); if ((end = times(&tmsend)) == -1) /* ending values */ err_sys("times error"); pr_times(end-start, &tmsstart, &tmsend); pr_exit(status); Figure 8.30 printf("\ncommand: %s\n", cmd); /* starting values */ if ((start = times(&tmsstart)) == -1) err_sys("times error");

Process Times static void pr_times(clock_t real, struct tms *tmsstart, struct tms *tmsend) { static long clktck = 0; if (clktck == 0) /* fetch clock ticks per second first time */ if ((clktck = sysconf(_sc_clk_tck)) < 0) err_sys("sysconf error"); printf(" real: %7.2f\n", real / (double) clktck); printf(" user: %7.2f\n", (tmsend->tms_utime - tmsstart->tms_utime) / (double) clktck); printf(" sys: %7.2f\n", (tmsend->tms_stime - tmsstart->tms_stime) / (double) clktck); printf(" child user: %7.2f\n", (tmsend->tms_cutime - tmsstart->tms_cutime) / (double) clktck); } printf(" child sys: %7.2f\n", (tmsend->tms_cstime - tmsstart->tms_cstime) / (double) clktck); Figure 8.30