Understanding Process Relationships in Unix Systems
Explore the relationship between processes, process groups, sessions, and controlling terminals in Unix systems. Learn how signals can be sent to process groups, the concept of session leadership, and the role of controlling processes in managing I/O devices.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Job Control and Process Relationships Question: A program like shell can create many processes. When we type Ctrl-C, which process should be interrupted? See the behavior in a typical shell
Job Control and Process Relationships UNIX process relationship Parent/child Group Session Job control Foreground and background processes Given that many processes can be executed concurrently, which processes should have accesses to the keyboard/screen (I/O)? Our discussion will focus on systems (shells) supporting job control Readings APUE Ch9
Process Groups A process group is a collection of (related) processes. Each group has a process group ID. Each group has a group leader whose pid = pgid To get the group ID of a process: pid_t getpgrp(void) In shell, try ps -f j u username A signal can be sent to the whole group of processes.
Process Groups A process may join an existing group, create a new group. int setpgid(pid_t pid, pid_t pgid) A process can set group ID of itself or its children _POSIX_JOB_CONTROL must be defined Most shells with job control create new group for each line of command (job).
Sessions A session is one or more process groups proc1 | proc2 & proc3 | proc4 | proc5 results in a session with three groups proc1 proc3 Login shell proc2 proc4 proc5 A login shell is a session in general. See example2.c
Sessions To establish a new session: pid setsid(void); Process become the session leader Process become a new group leader of a new group Process has no controlling terminal (break up the old one) Each shell is a session. When a shell is created, a terminal must be setup. Fails if the caller is a group leader.
Session A session can have a single controlling terminal for performing I/O Terminal device for a terminal login Pseudo-terminal device for a network login The I/O devices somewhat link to the window and keyboard. /dev/tty is synonym of controlling terminal The session leader that establishes the connection to the control terminal is called the controlling process.
Session Only one I/O device for all processes (and process groups) in a session. Which process should get the input from the keyboard? Foreground and background process One foreground group Many background groups Input Only foreground group Terminal s interrupt signals are only sent to the processes in the foreground group Output Typically shared
Sessions A process can open file /dev/tty to talk to controlling terminal regardless of how std IO are redirected. A way to by pass I/O redirection, see example1.c However, this process must be foreground process When background process tries to open /dev/tty, error occur
Foreground and Background How to make a group foreground and background? So that the terminal device driver knows where to send the terminal input and the terminal-generated signals. See mymore.c (foreground and background execution) pid_t tcgetpgrp(int filedes); /* return the foreground process group ID associated with filedes */ int tcsetpgrp(int filedes, pid_t pgrpid); /* makes the process group with process group ID pgrpid the foreground process group on the terminal associated to fd */ pgrpid must be group ID in the same session.
Job Control Allows starting multiple jobs from a single terminal and control which job can access the terminal. Foreground jobs can access terminal Background jobs may not: When a backgound job try to read, SIGTTIN signal is sent A background job may be able to output to the terminal (options may be set by the stty command) See control.c for an example of switching terminal among groups.
Orphaned Process Group Parent of every member is either in the orphaned group or is not a member of the group s session. Happens when a process forks a child and then dies. The child becomes a member of the orphaned group. Can have problems: the child may transform from a foreground process to a background process automatically. Remember in the control.c program, foreground group is set in both the parent and the child. Can be in an inconsistent state. If any IO is involved, strange things may happen.
Terminal I/O and Signals How to make sure that a shell program handles terminal I/O and signals correctly Create a new group for each job Both parent and child do setpgid For foreground job: After fork, shell set tcsetpgrp to give foreground jobs control over terminal Shell waits for all foreground processes in the foreground job to finish. After that, shell set tcsetpgrp to itself and print the prompt. For background job: Create a separate group so that processes in background jobs do not have access to terminal.
Up to now, we have focused on systems (shells) supporting job control How about shells do not support job control?
Shells with vs. without Job Control Up to now, we have focused on systems (more precisely, shells) supporting job control How about shells that do not support job control Such as the original Bourne shell (sh) Note that, on Linux, sh is linked to bash (which supports job control) You can try the behavior of sh on program.cs.fsu.edu
Shells without Job Control No new sessions or process groups are created All processes are in the same session and same group No background process groups vs. foreground process groups It will not use tcsetpgrp() to set foreground process group We do have background process(es) in shells without job control, such as sh In the sense that parent process (sh) will not wait for background process(es) to finish After forking a child process to run a command, the shell continues to show prompt to accept user input The next line of user input should be the next command line to shell, not the input to the background process(es)
Shells without Job Control How do we guarantee that the next line is for shell, not read by the background command? It depends on if the standard input of the command has been redirected to a file If yes, the shell does nothing special If no, the shell will redirect the standard input of the command to /dev/null before invoking the command As a consequence, in case the command will read from standard input, it will get nothing (immediately encounter end of file)
Shells without Job Control How about accessing file /dev/tty in shells without job control? Every process can open it Since, from terminal device driver s viewpoint, they are all in the same process group (no background process group or foreground process group)
