Linux basics from the founder of Gentoo. Part 2 (3/5): Process Management

This passage covers process control commands. You will learn how to freeze processes, defrost, send to the background, change the priority, view running processes and brutally kill them. Introduced the concept of signals. Commands such as bg, fg, jobs, kill, nohup, nice, renice, ps and top are considered.

Navigating Linux basics from the founder of Gentoo:

Part I

1. BASH: Basics of Navigation (Intro)
2. File and Directory Management
3. Links, and deleting files and directories
4. Glob-substitutions (totals and links)

Part II

1. Regular Expressions (Intro)
2. Folder Assignments, File Search
3. Process management
4. Text processing and redirection
5. Kernel modules (totals and links)

Process management

Running xeyes

To study process management, you must first start a process. Make sure that you have X running (graphical server - approx. Lane) and run the following command:

$ xeyes -center red

You will see a pop-up window xeyes and red eyes tracking the mouse cursor. Also, note that you did not have an invitation to enter commands in the terminal.

')

Process stop

To return the prompt, you must press Control-C (often written as Ctrl-C or ^ C):

You received your invitation back, but the xeyes window was gone. In fact, the process was "killed." Instead of completing Control-C, we can simply stop the process with Control-Z:

$ xeyes -center red
Control-Z

  [1] + Stopped xeyes -center red 

$

This time you will receive a bash'a prompt, and the xeyes window will remain on top. If you play with him a little, you may notice that his eyes are frozen in one place. If the xeyes window is blocked by another window and then open again, you will see that it has not even been redrawn. The process does nothing. He actually stopped.

fg and bg

In order to “stir up” the process and start it back, we can bring it to the forefront using the fg command.

$ fg
(test it out, then stop the process again)
Control-Z

  [1] + Stopped xeyes -center red 

$

And now let's continue it in the background with the help of the bg command.

$ bg
[1]+ xeyes -center red &
$

Perfectly! The xeyes process is now running in the background, and we again have the bash prompt.

Using "&"

If we need to immediately run xeyes in the background (instead of using Control-Z and bg), we can simply add an “&” (ampersand) to the end of the xeyes command:

$ xeyes -center blue &
[2] 16224

Multiple background processes

Now, in the background, we simultaneously work red and blue xeyes. We can view a list of jobs using jobs:

 $ jobs -l 
 [1]- 16217 Running xeyes -center red & [2]+ 16224 Running xeyes -center blue & 

The number in the left column is the order number of the task that bash assigns to it at startup. Plus (+) in the second task means that this is the “current task”, it will be brought to the foreground as you enter fg . You can also bring to the fore a specific task by indicating its number; for example, fg 1 will make those xeyes red. The next column is the process identifier or pid abbreviated kindly added to the output thanks to the -l option. Finally, the state of both processes is “Running” (running) and their command line is on the right.

Introduction to signals

To kill, stop, or continue the process, Linux uses a special form of interaction called signals. By sending a signal to some process, you can complete it, stop it, or do something else. This is what actually happens when you press Control-C, Control-Z, or use bg and fg — you tell bash to send a specific signal to the process. Signals can also be sent using the kill command, specifying it as the process id parameter (pid):

 $  kill -s SIGSTOP 16224 
 $  jobs -l 
 [1]- 16217 Running xeyes -center red & [2]+ 16224 Stopped (signal) xeyes -center blue 

As you can see, kill does not necessarily “kill” the process, although it can and this. Using the -s option, kill can send any signal to the process. Linux kills, stops, or continues processes when they receive a SIGINT, SIGSTOP, or SIGCONT signal, respectively. There are other signals you can send to processes; some signals can be processed within the programs themselves. You can find out about the signals that a particular program handles by searching the SIGNALS section in its man'e.

SIGTERM and SIGINT

If you want to kill the process, there are several options. By default, kill sends SIGTERM, which is different from SIGINT sent via Control-C, but usually has the same effect:

 $ kill 16217 
 $ jobs -l 
 [1]- 16217 Terminated xeyes -center red [2]+ 16224 Stopped (signal) xeyes -center blue 

Complete kill

A process can ignore both signals, SIGTERM and SIGINT, either at its discretion, or because it is stopped, or still somehow “stuck”. In this case, it may be necessary to use a large hammer - a SIGKILL signal. The process cannot ignore SIGKILL:

$ kill 16224
$ jobs -l

  [2] + 16224 Stopped (signal) xeyes -center blue 

 $  kill -s SIGKILL 16224 
 $  jobs -l 
 [2]+ 16224 Interrupt xeyes -center blue 

nohup

The terminal in which you run jobs is called a job control terminal. Some shells (but not bash by default) send a SIGHUP signal to background jobs when you exit, forcing them to complete. To protect processes from such behavior, use nohup when you start the process:

$ nohup make &
[1] 15632
$ exit

Use ps to list processes

The jobs command that we used previously displays only those processes that were running in your bash session. To see all the processes on your system, use ps with the a and x options:

 $  ps ax 
 PID TTY STAT TIME COMMAND 1 ? S 0:04 init [3] 2 ? SW 0:11 [keventd] 3 ? SWN 0:13 [ksoftirqd_CPU0] 4 ? SW 2:33 [kswapd] 5 ? SW 0:00 [bdflush] 

Only the first 5 processes are listed here, since the process list is usually very long. The team gives you a "cast" of everything that is currently running on the machine, but there is a lot of unnecessary information in it. If you did not specify an ax , you would receive a list of only those processes that belong to you and that exist in the control terminal. The ps x command will show all your processes, even those that are not in the control terminal. If you use ps a , you will get a list of processes from the terminals of all users.

View the "forest" and "trees"

You can also view other information about each process. The --forest option allows you to easily view the hierarchy of processes and give you an idea of ​​how the various processes in the system are interconnected. If one process starts another process, then the running one will be called its descendant. In the output --forest, the parents are on the left, and the descendants appear as branches on the right:

 $  ps x --forest 
 PID TTY STAT TIME COMMAND 927 pts/1 S 0:00 bash 6690 pts/1 S 0:00 \_ bash 26909 pts/1 R 0:00 \_ ps x --forest 19930 pts/4 S 0:01 bash 25740 pts/4 S 0:04 \_ vi processes.txt 

"U" and "l" options ps

The u and l options can be used in any combination with the a , x options in order to obtain more detailed information on the processes:

$ ps au

  USER PID% CPU% MEM VSZ RSS TTY STAT START TIME COMMAND
 agriffis 403 0.0 0.0 2484 72 tty1 S 2001 0:00 -bash
 chouser 404 0.0 0.0 2508 92 tty2 S 2001 0:00 -bash
 root 408 0.0 0.0 1308 248 tty6 S 2001 0:00 / sbin / agetty 3
 agriffis 434 0.0 0.0 1008 4 tty1 S 2001 0:00 / bin / sh / usr / X
 chouser 927 0.0 0.0 2540 96 pts / 1 S 2001 0:00 bash 

$ ps al

  F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
 100 1001 403 1 9 0 2484 72 wait4 S tty1 0:00 -bash
 100 1000 404 1 9 0 2508 92 wait4 S tty2 0:00 -bash
 000 0 408 1 9 0 1308 248 read_c S tty6 0:00 / sbin / ag
 000 1001 434 403 9 0 1008 4 wait4 S tty1 0:00 / bin / sh
 000 1000 927 652 9 0 2540 96 wait4 S pts / 1 0:00 bash 

Use top

If you find that you run ps several times in a row, trying to see the changes taking place, you may need to use top. The top program displays a constantly updated list of processes, along with other useful information:

 $  top 
 10:02pm up 19 days, 6:24, 8 users, load average: 0.04, 0.05, 0.00 75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 1.3% user, 2.5% system, 0.0% nice, 96.0% idle Mem: 256020K av, 226580K used, 29440K free, 0K shrd, 3804K buff Swap: 136544K av, 80256K used, 56288K free 101760K cached PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 628 root 16 0 213M 31M 2304 S 0 1.9 12.5 91:43 X 26934 chouser 17 0 1272 1272 1076 R 0 1.1 0.4 0:00 top 652 chouser 11 0 12016 8840 1604 S 0 0.5 3.4 3:52 gnome-termin 641 chouser 9 0 2936 2808 1416 S 0 0.1 1.0 2:13 sawfish 

nice

Each process has its own priority value, which Linux uses to divide CPU time. You can specify the priority of the process when it is started using the nice command:

$ nice -n 10 oggenc /tmp/song.wav

Since priority became known as nice, it has become easier to memorize, for example, the greater nice value does “good” (nice - good, wonderful; note lane) to other processes, allowing them to get higher priority access to CPU time. By default, processes are started with priority 0, so setting the priority to 10 for oggenc means that it will allow more time for other processes to work. As a rule, this means that oggenc will allow other processes to run at their normal speed, regardless of how long the processor oggenc wants. You could see these “courtesy levels” in the NI column in ps and top earlier.

renice

The nice command can only change the priority of processes during their launch. If you need to change the priority of a running process, use the renice command:

 $  ps l 641 
 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 0 5876 2808 do_sel S ? 2:14 sawfish 
 $ renice 10 641 
 641: old priority 0, new priority 10 
 
 $ ps l 641 
 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 10 5876 2808 do_sel S ? 2:14 sawfish 

$ ps l 641
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 0 5876 2808 do_sel S ? 2:14 sawfish
$ renice 10 641
641: old priority 0, new priority 10

$ ps l 641
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 10 5876 2808 do_sel S ? 2:14 sawfish

 $  ps l 641 
 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 0 5876 2808 do_sel S ? 2:14 sawfish 
 $ renice 10 641 
 641: old priority 0, new priority 10 
 
 $ ps l 641 
 F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 000 1000 641 1 9 10 5876 2808 do_sel S ? 2:14 sawfish 

Thank you Dmitry Minsky (Dmitry.Minsky@gmail.com) for the translation.

Continued ...

---

About the authors

Daniel Robbins

Daniel Robbins is the founder of the Gentoo community and the creator of the Gentoo Linux operating system. Daniel lives in New Mexico with his wife, Mary, and two energetic daughters. He is also the founder and head of Funtoo , has written many technical articles for IBM developerWorks , Intel Developer Services and the C / C ++ Users Journal.

Chris Houser

Chris Hauser was a UNIX supporter since 1994 when he joined the team of administrators at Taylor University (Indiana, USA), where he received a bachelor's degree in computer science and mathematics. After that, he worked in many areas, including web applications, video editing, drivers for UNIX, and cryptographic protection. Currently working in Sentry Data Systems. Chris also contributed to many free projects, such as Gentoo Linux and Clojure, co-authored The Joy of Clojure .

Aron griffis

Airon Griffis lives in Boston, where he spent the last decade working with Hewlett-Packard on projects such as UNIX network drivers for Tru64, Linux security certification, Xen and KVM virtualization, and most recently, the HP ePrint platform. In his spare time, Airon prefers to ponder over the problems of programming while riding his bike, juggling bits, or cheering on the Boston Red Baseball team.