Linux Chapter 9.docx

**A typical Linux system can run thousands of processes simultaneously, including** those that you have explored in previous chapters. In this chapter, you focus on viewing and managing processes. In the first part of the chapter, you examine the different types of processes on a Linux system and ho...

**A typical Linux system can run thousands of processes simultaneously, including** those that you have explored in previous chapters. In this chapter, you focus on viewing and managing processes. In the first part of the chapter, you examine the different types of processes on a Linux system and how to view them and terminate them. You then discover how processes are executed on a system, run in the background, and prioritized. Finally, you examine the various methods used to schedule commands to execute in the future. Throughout this book, the terms "program" and "process" are used interchangeably. The same is true in the workplace. However, a fine distinction exists between these two terms. Technically, a **program** is an executable file on the hard disk that can be run when you execute it. A **process**, on the other hand, is a program that is running in memory and on the CPU. In other words, a process is a program in action. If you start a process while logged in to a terminal, that process runs in that terminal and is labeled a [**user process**](javascript://). Examples of user processes include ls, grep, and find, not to mention most of the other commands that you have executed throughout this book. Recall that a system process that is not associated with a terminal is called a [**daemon process**](javascript://); these processes are typically started on system startup, but you can also start them manually. Most daemon processes provide system services, such as printing, scheduling, and system maintenance, as well as network server services, such as Web servers, database servers, file servers, and print servers. Every process has a unique [**process ID (PID)**](javascript://) that allows the kernel to identify it uniquely. In addition, each process can start an unlimited number of other processes called [**child processes**](javascript://). Conversely, each process must have been started by an existing process called a [**parent process**](javascript://). As a result, each process has a [**parent process ID (PPID)**](javascript://), which identifies the process that started it. An example of the relationship between parent and child processes is depicted in [Figure 9-1](javascript://). **Figure 9-1** Parent and child processes Figures shows parent and child processes. The diagram is the form of an inverted tree with 3 levels starting with a single process at the root or first level. The details of the processes are given for each process. The following is the process at the root or level 1. Name of the process, Process number 1; Process I D, 134; Parent Process I D, 56. The following are the processes at level 2. They derive from Process number 1. Name of the process, Process number 2; Process I D, 291; Parent Process I D, 134. Name of the process, Process number 3; Process I D, 348; Parent Process I D, 134. The following are the processes at level 3. They derive from Process number 2. Name of the process, Process number 4; Process I D, 448; Parent Process I D, 291. Name of the process, Process number 5; Process I D, 571; Parent Process I D, 291. **Note ** PIDs are not necessarily given to new processes in sequential order; each PID is generated from free entries in a process table used by the Linux kernel. Remember that although each process can have an unlimited number of child processes, it can only have one parent process. The first process started by the Linux kernel is the initialize (or init) daemon, which has a PID of 1 and a PPID of 0, the latter of which refers to the kernel itself. The init daemon then starts most other daemons during the system initialization process, including those that allow for user logins. After you log in to the system, the login program starts a BASH shell. The BASH shell then interprets user commands and starts all user processes. Thus, each process on the Linux system can be traced back to the init daemon by examining the series of PPIDs, as shown in [Figure 9-2](javascript://). **Figure 9-2** Process genealogy Figure shows process genealogy in Linux. Initially, there is the init daemon. The init daemon begins other daemons. One of these daemons is responsible for running the user login process. From the user login, the Bash shell is spawned. The Bash shell is then responsible for running several user processes. **Note ** The init daemon is often referred to as the "grandfather of all user processes." On Linux systems that use the UNIX SysV system initialization process, the init daemon will be listed as init within command output. On Linux systems that use the Systemd system initialization process, the init daemon will either be listed as init or systemd within command output. Although several Linux utilities can view processes, the most versatile and common is the [**ps command**](javascript://). Without arguments, the ps command simply displays a list of processes that are running in the current shell. The following example shows the output of this command while the user is logged in to tty2: The preceding output shows that two processes were running in the terminal tty2 when the ps command executed. The command that started each process (CMD) is listed next to the time it has taken on the CPU (TIME), its PID, and terminal (TTY). In this case, the process took less than one second to run, and so the time elapsed reads nothing. To find out more about these processes, you could instead use the --f, or full, option to the ps command, as shown next:  This listing provides more information about each process. It displays the user who started the process (UID), the PPID, the time it was started (STIME), as well as the CPU utilization (C), which starts at zero and is incremented with each processor cycle that the process runs on the CPU. The most valuable information provided by the ps --f command is each process's PPID and lineage. The bash process (PID = 2159) displays a shell prompt and interprets user input; it started the ps process (PID = 2233) because the ps process had a PPID of 2159. Because daemon processes are not associated with a terminal, they are not displayed by the ps --f command. To display an entire list of processes across all terminals and including daemons, you can add the --e option to any ps command, as shown in the following output:  As shown in the preceding output, the kernel thread daemon (kthreadd) has a PID of 2 and starts most subprocesses within the actual Linux kernel because those subprocesses have a PPID of 2, whereas the init daemon (/usr/lib/systemd/systemd, PID = 1) starts most other daemons because those daemons have a PPID of 1. In addition, there is a ? in the TTY column for daemons and kernel subprocesses because they do not run on a terminal. Because the output of the ps --ef command can be several hundred lines long on a Linux server, you usually pipe its output to the less command to send the output to the terminal screen page-by-page, or to the grep command, which can be used to display lines containing only certain information. For example, to display only the BASH shells on the system, you could use the following command:  Notice that the grep bash command is also displayed alongside the BASH shells in the preceding output because it was running in memory at the time the ps command was executed. This might not always be the case because the Linux kernel schedules commands to run based on a variety of factors. The --e and -f options are the most common options used with the ps command; however, many other options are available. The --l option to the ps command lists even more information about each process than the --f option. An example of using this option to view the processes in the terminal tty2 is shown in the following output:  The process flag (F) indicates particular features of the process; the flag of 4 in the preceding output indicates that the root user ran the process. The [**process state**](javascript://) (S) column is the most valuable to systems administrators because it indicates what the process is currently doing. If a process is not being run on the processor at the current time, you see an S (interruptible sleep) in the process state column; processes are in this state most of the time and are awoken (interrupted) by other processes when they are needed, as seen with bash in the preceding output. You will see an R in this column if the process is currently running on the processor, a D (uninterruptible sleep) if it is waiting for disk access, or a T if it has stopped or is being traced by another process. In addition to these, you might also see a Z in this column, indicating a [**zombie process**](javascript://). When a process finishes executing, the parent process must check to see if it executed successfully and then release the child process's PID so that it can be used again. While a process is waiting for its parent process to release the PID, the process is said to be in a zombie state, because it has finished but still retains a PID. On a busy Linux server, zombie processes can accumulate and prevent new processes from being created; if this occurs, you can kill the parent process of the zombies, as discussed in the next section. **Note ** Zombie processes are also known as defunct processes. To view a list of zombie processes on your entire system, you could use the ps --el \| grep Z command. [**Process priority**](javascript://) (PRI) is the priority used by the kernel for the process; it is measured between 0 (high priority) and 127 (low priority). The [**nice value**](javascript://) (NI) can be used to affect the process priority indirectly; it is measured between −20 (a greater chance of a high priority) and 19 (a greater chance of a lower priority). The ADDR in the preceding output indicates the memory address of the process, whereas the WCHAN indicates what the process is waiting for while sleeping. In addition, the size of the process in memory (SZ) is listed and measured in kilobytes; often, it is roughly equivalent to the size of the executable file on the filesystem. Some options to the ps command are not prefixed by a dash character; these are referred to as Berkeley style options. The two most common of these are the a option, which lists all processes across terminals, and the x option, which lists processes that do not run on a terminal, as shown in the following output for the first 10 processes on the system:  The columns just listed are equivalent to those discussed earlier; however, the process state column is identified with STAT and might contain additional characters to indicate the full nature of the process state. For example, a W indicates that the process has no contents in memory, a \