1. Process relationships
S.W. Tak
Chapter9: Process Relationships

2. 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

3. 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. 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

5. 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

6. 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

7. 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

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

9. 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 )
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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

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

27. 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 sh 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 & 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
cat1 ps
Chapter9: Process Relationships

28. Shell Execution of Programs (Cont’d)
$ps –xj | cat1 |cat2
PPID PID PGID SID TPGID COMMAND sh
cat2 ps
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

29. Shell Execution of Programs (Cont’d)
We’ll use the KornShell that support job control
$ ps –xj
PPID PID PGID SID TPGID COMMAND
ksh 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 &
ksh 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

30. Shell Execution of Programs (Cont’d)
$ps-xj | cat1
PPID PID PGID SID TPGID COMMAND
ksh ps
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 &
ksh
cat1 ps
The KornShell generates the processes in the same fashion as the Bourn shell.
Chapter9: Process Relationships

31. 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

32. 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

33. 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