Process relationships S.W. Tak Chapter9: Process Relationships

Introduction Relationships between different processes Every process has a parent process The parent is notified when the child terminates The parent can obtain the child’s status It is impossible to describe these relationships without talking about signals, and to talk about signals we need many of the concepts in this chapter Chapter9: Process Relationships

4.3+BSD Terminal Logins When the system is bootstrapped, the kernel creates process ID 1, the init process, and it is init that brings the system up multiuser. The init reads the /etc/ttys (Linux: /etc/inittab) For every terminal device (with RS-232 connections) that allows a login, init does a fork followed by an exec of the program getty (Linux: /sbin/agetty) Chapter9: Process Relationships

4.3+BSD Terminal Logins (Cont’d) init getty exec fork forks once per terminal Each child execs getty real user id 0, euid 0 Have empty environment Chapter9: Process Relationships

4.3+BSD Terminal Logins (Cont’d) See Figure 9.1 (Page 238): Processes invoked by init to allow terminal logins All the processes shown in Figure 9.1 Real User ID: 0 (Superuser) Effective User ID: 0 (Superuser) The init also execs getty program with an empty environment It is getty that calls open for the terminal device The terminal is opened for reading and writing Once the device is open, file descriptor 0, 1, and 2 are set to device getty is done when we enter our user name. It then invokes the login program, similar to execle(“/usr/bin/login”, “login”, “-p”, username, (char *)0, envp); There can be options in the gettytab file to have it invoke other programs) init invokes getty with an empty environment getty creates an environment for login (the envp environment) with the name of terminal (e.g., TERM=vt100, where the type of terminal vt100 is taken from the gettytab file) and any environment strings that are specified in the gettytab. -p flag to login tells it to preserve the environment that it is passed and andd to that environment, not replace it. Chapter9: Process Relationships

4.3+BSD Terminal Logins (Cont’d) reads /etc/ttys; forks once per terminal; create empty environment init fork init exec opens terminal device (file descriptors 0,1,2); reads user name; initial environment set getty exec login all are super user privileges Chapter9: Process Relationships

4.3+BSD Terminal Logins (Cont’d) See Figure 9.2 (Page 239): State of processes after login has been invoked All the processes shown in Figure 9.2 have super user privileges init process has superuser privileges and the process ID does not change across an exec. All the processes other than the original init process have a parent process ID of ONE. Chapter9: Process Relationships

Network Logins (Cont’d) init through getty and login login shell terminal device driver RS-232 connection user at a terminal Chapter9: Process Relationships

4.3+BSD Terminal Logins (Cont’d) login does many things (login really does more than we’ve described here!!, e.g. checks for new email) Call getpwname to fetch our password file Call getpass(3) to display the prompt password: If the login attempt fails, login calls exit with an argument 1 This termination will be noticed by the parent (init) It will do another fork followed by an exec of getty. If we log in correctly login changes to our home directory (chdir) The ownership of our terminal device is changed (chown) Our group IDs are set, by calling setgid and then initgroups. The environment is then initialized with all the information that login has: Our home directory (HOME), shell (SHELL), user name (USER and LOGNAME), and a default path (PATH) Finally, it changes to our user ID (setuid) and invokes our login shell execl(“/bin/sh”, “-sh”, (char *)0); /* The minus sign as the first character of argv[0] is a flag to all the shells that they are being invoked as a login shell The parent process ID of login shell is the original init. When our login shell terminates, init is notified (it is sent a SIGCHILD signal) Chapter9: Process Relationships

Network Logins Terminal logins Network logins init knows which terminal devices are enabled for logins and spawns a getty process for each device Network logins All the logins come through the kernel’s network interface drivers We don’t know ahead of time how many of these will occur We have to wait for a network connection request to arrive. There are a single process that waits for most network connections, the inetd process , called the Internet superserver. When a connection request arrives for it to handle, it does a fork and exec of the appropriate program. P. 242: Figure 9.4: Sequence of processes involved in executing TELNET server P. 242: Figure 9.5: Arrangement of processes after everything is set for a network login Chapter9: Process Relationships

Network Logins (4.3+BSD) init login shell user at a terminal through inetd,telnetd,and login login shell fd 0,1,2 pseudo-terminal device driver network connection through telnetd server and telnet client user at a terminal Chapter9: Process Relationships

Process Group Process Group A collection of one or more processes Each process group has a unique process group ID Each process group can have a process group leader The leader is identified by having its process group ID equal its process ID. Group leader can create processes in the group and then terminates The process group still exists, as long as there is at least one process in the group, regardless whether the group leader terminates or not. #include <sys/types.h> #include <unistd.h> pid_t getpgrp(void); Chapter9: Process Relationships

Process Group (Cont’d) A process joins an existing process group or creates a new process group A process can set the process group ID of only itself or one of its children. It can’t change the process group ID of one of its children after that child has called one of exec functions. #include <sys/types.h> #include <unistd.h> int setpgid(pid_t pid,pid_t pgid); if pid == pgid, pid will be group leader if pid == 0 the process ID of the caller is used if pgid == 0 pid is used as the process group ID if system does not support job control, (we talk about job control in Section 9.8), _POSIX_JOB_CONTROL won’t be defined, and this function returns an error with errno set to ENOSYS Chapter9: Process Relationships

Process Group (Cont’d) In most job-control shells setpgid(pid_t pid, pid_t pgid) function is called after a fork to have the parent set the process group ID of the child, and to have the child set its own process group ID. One of these calls is redundant However, by doing both we are guaranteed that the child is placed into its own process group before either process assumes that this has happened. We can send a signal to either a single process (identified by its process ID) or to a process group (identified by its process group) The waitpid function from Section 8.6 lets us wait for either a single process or one process from a specified process group. Chapter9: Process Relationships

Sessions Session A collection of one or more process groups The processes in a process group are usually grouped together into the process group by a shell pipeline Create 3 process groups in a single session proc1 | proc2 & proc3 | proc4 | proc5 Chapter9: Process Relationships

Sessions (Cont’d) Proc 3 Proc 1 Login shell Proc 4 Proc 2 process group Proc 5 process group process group Session Chapter9: Process Relationships

Sessions (Cont’d) #include <sys/types.h> #include <unistd.h> pid_t setsid(void); Establish a new session Return an error if the caller is already a process group leader If the calling process is not a process group leader, this function creates a new session The process becomes the session leader of a new session group. The process is the only process in this new session The process becomes the process group leader of a new process group. The new process group ID is the process ID of a calling process. The process has no controlling terminal. If the process had a controlling terminal before calling setsid, that association is broken. We are guaranteed that the child is not a process group leader because the process group ID of the parent is inherited by the child, but the child gets a new process ID Hence it is impossible for the child’s process ID to equal its inherited process group ID Chapter9: Process Relationships

Controlling Terminal Characteristics A session can have a single controlling terminal Terminal device or pseudo-terminal device controlling process The session leader that establishes the connection to the controlling terminal The process groups within a session can be divided a single foreground process group one or more background process groups Chapter9: Process Relationships

Controlling Terminal (Cont’d) If a session has a controlling terminal It has a single foreground process group All others are background process groups Whenever user input terminal’s interrupt key(Ctrl-C) or quit key(Ctrl-\), This causes either the interrupt signal or the quit signal to be sent to all processes in the foreground process group If a modem disconnection is detected by the terminal interface, the hang-up signal is sent to the controlling process (the session leader) Chapter9: Process Relationships

Controlling Terminal (Cont’d) Proc 3 Proc 1 Login shell Proc 4 Proc 2 Proc 5 background process group session leader = controlling process background process group Foreground process group Terminal input and terminal-generated signal Modem disconnect (hangup signal) Controlling terminal Chapter9: Process Relationships

Controlling Terminal (Cont’d) If a program wants to talk to the controlling terminal open /dev/tty /dev/tty is synonym for the controlling terminal Opening /dev/tty by the program which doesn’t have a controlling terminal will fail. Chapter9: Process Relationships

Job Control Job Control Allows user to start multiple jobs from a single terminal Control which jobs can access the terminal Control which jobs are to run in the background Requires A shell that supports job control The terminal driver in the kernel must support job control Support for certain job-control signals must be provided Chapter9: Process Relationships

Job Control (Cont’d) A job Example Collection of process often a pipeline of processes Example $make all > Make.out & [1] 1475 $pr *.c | lpr & [2] 1490 $ [2] + Done pr *.c | lpr & [1] + Done make all > Make.out & Chapter9: Process Relationships

Job Control (Cont’d) Starting Job in background & Make foreground job to background job Ctrl-Z bg Make background job to foreground job fg %1 fg % Chapter9: Process Relationships

Job Control (Cont’d) $ cat > temp.foo & [1] 1681 $ [1] + Stopped (tty input) cat>temp.foo& $fg %1 cat > temp.foo hello, world ^D $cat temp.foo Chapter9: Process Relationships

Job Control (Cont’d) See Fig 9.8 Chapter9: Process Relationships

Shell Execution of Programs We’ll use a shell doesn’t support job control – the classic Bourne shell $ ps –xj PPID PID PGID SID TPGID COMMAND 1 163 163 163 163 -sh 168 163 163 163 ps TPGID (Terminal Process Group ID) column shows the foreground process group. Note: It is a misnormer to associate a process with a terminal process group ID (the TPGID column). A process does not have a terminal process control group. A process belongs to a process group, and the process group belongs to a session. The session may or may not have a controlling terminal. If it does have a controlling terminal, then the terminal device knows the process group ID of the foreground process. $ ps –xj & 169 163 163 163 ps The background job is not put into its own process group, and the controlling terminal isn’t taken away from the background job, because this shell doesn’t know about job control. $ps-xj | cat1 163 200 163 163 163 cat1 200 201 163 163 163 ps Chapter9: Process Relationships

Shell Execution of Programs (Cont’d) $ps –xj | cat1 |cat2 PPID PID PGID SID TPGID COMMAND 1 163 163 163 163 -sh 163 202 163 163 163 cat2 202 203 163 163 163 ps 202 204 163 163 163 cat1 exec sh (203) ps (203) fork sh (163) fork sh (202) pipeline fork exec sh (204) cat1 (204) exec notification to parent on termination cat2 (202) pipeline Chapter9: Process Relationships

Shell Execution of Programs (Cont’d) We’ll use the KornShell that support job control $ ps –xj PPID PID PGID SID TPGID COMMAND 1 700 700 700 708 -ksh 708 708 700 708 ps We immediately have a difference from our Bourne shell example. The Kornshell places the foreground job (ps) into its own process group (708). The PS command is the process group leader and the only process in this process group. This process group is the foreground process group since it has the controlling terminal. Our login shell is a background process group while the ps command executes. $ ps –xj & 1 700 700 700 700 -ksh 709 709 700 700 ps The process group (709) is no longer the foreground process group. It is a background process group. The TPGID of 700 indicates that the foreground process group is our login shell. Chapter9: Process Relationships

Shell Execution of Programs (Cont’d) $ps-xj | cat1 PPID PID PGID SID TPGID COMMAND 1 700 700 700 710 -ksh 700 710 710 700 710 ps 700 711 710 700 710 cat1 Another difference between this example and the similar Bourne shell example. The Bourne shell created the last process in the pipeline first, and this final process was the parent of the first process. $ps –xj | cat1 & 1 700 700 700 700 -ksh 712 712 700 700 cat1 712 713 712 700 700 ps The KornShell generates the processes in the same fashion as the Bourn shell. Chapter9: Process Relationships

Orphaned Process Group (Cont’d) A process whose parent terminates. See Figure 9.10 (P.256): Example of a process group about to be orphaned Assumption: a job-control shell Chapter9: Process Relationships

Orphaned Process Group (Cont’d) … int main(void) { char c; pid_t pid; pr_ids(“parent”); if((pid = fork()) < 0) err_sys(“fork error”); else if(pid > 0){ sleep(5); exit(0); }else{ pr_ids(“child”); signal(SIGHUP, sig_hup); /* stop ourself */ kill(getpid(), SIGTSTP); if(read(0, &c, 1) != 1) printf(“read error from control terminal, errno=%d\n”, errno); } static void sig_hup(int signo) printf(“SIGHUP received, pid = %d\n”, getpid()); return; static void pr_ids(char *name) printf(“%s: pid = %d, ppid = %d, pgrp = %d\n”, name, getpid(), getppid(), getpgrp()); fflush(stdout); The parent sleeps for 5 seconds This is a way for letting the child execute before the parent terminates The child establishes a signal handler (SIGHUP) The child sends itself the stop signal (SIGTSTP) with kill function This stop the child, similar to our stopping a foreground job with our terminal’s suspend character When the parent terminates, the child is orphaned, so the child’s parent process becomes 1. the init process ID At this point the child is now a member of an orphaned process group. Since the process group is orphaned when the parent terminates, POSIX.1 requires that every process in the newly orphaned process group that is stopped (as our child is) be sent the hang-up signal (SIGHUP) This causes the child to be continued, after processing the hang-up signal The default action for the hang-up signal is to terminate the process, which is why we have to provide a signal handler to catch the signal. Chapter9: Process Relationships

Orphaned Process Group (Cont’d) $ a.out parent: pid=512, ppid=442, pgrp=512 child: pid=513, ppid=512, pgrp=512 $SIGHUP received, pid=513 child: pid=513, ppid=1, pgrp=512 read error from control terminal, errno=5 The child is a member of an orphaned process group. When a background process group tries to read from its controlling terminal, SITTIN is generated for the background process group (See Figure 9.8: P. 251). Notice that our child becomes a background process group when the parent terminates, since the parent was executed as a foreground job by the shell. Chapter9: Process Relationships