12 - Linux Processes. nice factor. Ps command

Today we will talk about the processes in Linux , and the next lecture will be about the signals by which processes can interact with each other. For process management there is such a subsystem as a process manager . As mentioned earlier in Linux multitasking with preemption is implemented and the process manager completely controls the processes. Each process has its own context. The process context is the memory allocation table, the current process status, process priority, data on the resources used, signal mask, process identifiers, and other properties. A process identifier consists of a PID and a parent PPID .

As you already know, the very first user process is called init . Its PID is always 1, and PPID is 0, since it does not have a parent process, but is generated by the kernel at a certain stage of the system boot. All other processes are child processes and have a non-zero PPID . In order to spawn a new process, the parent calls the kernel function fork () , as a result of which the parent process is cloned and the process is exactly the same at the initial stage. The only difference is that the child process increases the PID . The PID of the child process will always be greater than the parent. The rest of the context will completely coincide with the parent. Then, for the child process, the exec () function is started, which begins to change the context to the desired one, load the program code into memory, etc.

The Linux operating system is also multi-user. Each process has a parameter such as “owner” - on whose behalf the process is executed. This is the UID of the process. Also, the process has such a parameter as GID (by analogy with the user's GID ). In addition, there are parameters such as EUID (effective UID ) and EGID (effective GID ). The capabilities of the process in the system are determined by these parameters: EUID and EGID .

EUID = User UID if setuid = 0
EUID = UID of the program if the bit setuid = 1

Only one process can work at a time. But since switching between processes happens very quickly (thousands of switches per second), it seems that they all work at the same time. How much processor time and other resources to allocate to each process is the process manager. In making this decision, the process parameter such as nice (or nice factor ) plays a role. nice factor is a numeric value. The more it is, the less resources (CPU time, etc.) will be allocated to the process during its operation.

Many processes perform input / output information to / from the terminal. Therefore, there is such a parameter as the Terminal. And there are processes that work in the background. Such processes are not tied to the terminal. For example, the cron process.

The process can be in several states:

1. Execution - the process manager has allocated all the necessary resources and the process just waits for its turn to receive the next portion of processor time.
2. Waiting - the process has received all the resources, but to continue the work he is waiting for some information, for example, from another process.
3. Stopped - the process does nothing, processor time does not receive. The process was transferred to this state with the help of special signals and it can also get out of this state only with the help of the corresponding signal.
4. “Zombies” is a process that was supposed to end with the release of all resources, but for some reason the completion did not happen correctly. With the processes of “Zombies” need to be careful. If such processes mean a lot in the system something is wrong.

To view the processes and their properties is designed com *** a ps . Com *** and has a lot of keys and parameters. All of them can be viewed in man ps . We will consider some of the most necessary for the administrator of the computer. I also want to draw attention to the fact that the ps program can transfer both parameters and keys. Let me remind you that before the key (or a sequence of keys) there is always a hyphen, and the parameters are written without a hyphen. Compare the results of the ps commands with the key ( ps -a ) and with the parameter ( ps a ). As you can see the results are significantly different. And now we will consider some more widespread options of the ps command.

To display all existing processes, use the com *** a ps aux command. The result is shortened below (there are many more processes):

igor @ adm-ubuntu: ~ / linux $ ps aux
USER PID% CPU% MEM VSZ RSS TTY STAT START TIME COMMAND
root 11740 0.0 0.0 3124 448? S <11:28 0:00 udevd --daemon
igor 11805 0.0 0.0 1848 548 pts / 0 S + 11:43 0:00 ping 192.168.222.10
igor 11915 0.0 0.1 2640 1040 pts / 2 R + 12:00 0:00 ps aux

With the command ps aux you can see a fairly extensive amount of information. The decryption of the columns is as follows:

USER - process owner
PID - PID process
% CPU is the percentage of processor usage. This is the processor usage time divided by the total process life.
% MEM is the percentage of physical RAM used.
VSZ - amount of virtual memory allocated to the process (in Kilobytes)
RSS - the amount of physical RAM allocated to the process (in kilobytes)
TTY - which terminal is the process tied to
STAT - status (status) of the process. R - execution, S - waiting, T - stopped, Z - “zombies”
START - the time when the process was started
TIME - the amount of CPU time that the process took. Usually there are zeros or a small number (0:00 - 0:09). If the number is large, the process loads the processor and you should check if everything is fine with it.
COMMAND is the name of the command. What code was executed during the execution of the exec () function.

To see information about the nice factor you need to execute a com *** in ps lax :

igor @ adm-ubuntu: ~ $ ps lax
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 1000 2760 1 20 0 17928 5512 poll_s Ss? 0:01 gnome-screensaver
0 1000 5859 3543 20 0 6292 3512 wait Ss pts / 2 0:00 bash
0 1000 12275 5859 20 0 3752 1564 wait S + pts / 2 0:00 man ps

Of particular interest to us are the following columns:

PPID — The PID of the parent process is displayed. For example, for the first line of the example, the PPID is 1, which means the init process is the parent for this process. The process from the third line is a child of the process from the second line, etc.
NI is a nice factor value.
PRI is the priority of the process.

Above I mentioned the nice factor as a parameter that affects the priority of the process. The higher the number in the PRI column, the lower the priority of the process. Users can change the priority of a process by changing the nice factor . There are two commands for this: nice and renice . The range of values ​​of the nice factor is small: from -20 to 19. When a child process is created, it inherits the nice factor of its ancestor. By default, most user processes have a nice factor of 0, since it is such a nice factor that is set for the init process. To change the nice factor of the process being started, use the *** *** nice command:

igor @ adm-ubuntu: ~ $ nice -n 5 sleep 30 &

igor @ adm-ubuntu: ~ $ ps lax | grep sleep
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 3567 3543 20 0 6292 3528 wait Ss pts / 0 0:00 bash
0 1000 13098 3567 25 5 2952 628 hrtime SN pts / 0 0:00 sleep 30

The command syntax is simple: using the -n key, we pass the value of the nice factor increment , and then comes the com *** and for which the new nice factor will be set. This is exactly the increment, since the real nice factor of the new process will be equal to the nice factor of the parent process combined with the number passed to the nice command. In the example above, the nice factor of the parent process ( the bash shell ) is zero, which means the nice factor of the child will be 0 + 5 = 5, which we see in the results.

Regular users can only increase the nice factor , but can not reduce it. This was done so that users could not create high-priority processes. If on behalf of the user we execute a com *** at nice -n -5 sleep 30 & , we get an error message. Only the root user can reduce the nice factor .

If it is necessary to change the nice factor of an already running process, then use the com *** in renice . For example:

igor @ adm-ubuntu: ~ $ renice 14 13229
13229: old priority 10, new priority 14

where 13229 is the PID of the process for which the nice factor is changing. From the example, it is also seen that the number 14 is no longer an increment, but simply a new value of the nice factor . If it is necessary to change the nice factor of all processes of a single user, the -u switch is used. For example, change the nice factor of all user test processes:

test @ adm-ubuntu: ~ $ ps lax | grep test
4 1001 13256 5630 20 0 8656 3036 wait S pts / 1 0:00 su - test
0 1001 13297 13266 20 0 3056 824 pipe_w S + pts / 1 0:00 grep –color = auto test
test @ adm-ubuntu: ~ $ renice 5 -u test
1001: old priority 0, new priority 5
test @ adm-ubuntu: ~ $ ps lax | grep test
4 1001 13256 5630 25 5 8656 3036 wait SN pts / 1 0:00 su - test
0 1001 13302 13266 25 5 3056 820 pipe_w SN + pts / 1 0:00 grep –color = auto test

For what practical purposes can you use the nice factor ? For example, if some processes currently take up a large amount of CPU time, then for a faster problem determination, you can run a command interpreter with a lower nice factor . Operations of various kinds of coding or compression, which require a lot of time (hours), can be run with a higher nice factor in order not to load the system. The speed of modern processors is such that they resort to changing the nice factor less and less, but nevertheless it can sometimes be very useful.

In the next lecture, let's talk about signals.