A process is a running program. Each process on the system has a numeric process ID (PID). For a quick listing of running processes, just run ps on the command line. You should get a list like this one:
$ ps
| PID | TTY | STAT | TIME | COMMAND |
| 520 | p0 | S | 0:00 | -bash |
| 545 | ? | S | 3:59 | /usr/X11R6/bin/ctwm -W |
| 548 | ? | S | 0:10 | xclock -geometry -0-0 |
| 2159 | pd | SW | 0:00 | /usr/bin/vi lib/addresses |
| 31956 | p3 | R | 0:00 | ps |
The fields are as follows:
- PID. The process ID.
- TTY. The terminal device where the process is running. More about this later.
- STAT. The process status, that is, what the process is doing and where its memory resides. For example, S means sleeping and R means running. (See the ps(1) manual page for a description of all the symbols.)
- TIME. The amount of CPU time in minutes and seconds that the process has used so far. In other words, the total amount of time that the process has spent running instructions on the processor.
- COMMAND. This one might seem obvious, but be aware that a process can change this field from its original value.
Command Options
The ps command has many options. To make things more confusing, you can specify options in three different styles—Unix, BSD, and GNU. Many people find the BSD style to be the most comfortable (perhaps because it involves less typing), so we’ll use the BSD style. Here are some of the most useful option combinations:
As with other programs, you can combine options, as in ps aux and ps auxw. To check on a specific process, add its PID to the argument list of the ps command. For example, to inspect the current shell process, you could use ps u $$, because $$ is a shell variable that evaluates to the current shell’s PID. (You’ll find information on the administration commands top and lsof in later videos. These can be useful for locating processes, even when doing something other than system maintenance.)
Killing Processes
To terminate a process, send it a signal with the kill command. A signal is a message to a process from the kernel. When you run kill, you’re asking the kernel to send a signal to another process. In most cases, all you need to do is this:
$ kill pid
There are many types of signals. The default is TERM, or terminate. You can send different signals by adding an extra option to kill. For example, to freeze a process instead of terminating it, use the STOP signal:
$ kill -STOP pid
A stopped process is still in memory, ready to pick up where it left off. Use the CONT signal to continue running the process again:
$ kill -CONT pid
Note: Using ctrl-c to terminate a process that is running in the current terminal is the same as using kill to end the process with the INT (interrupt) signal.
The most brutal way to terminate a process is with the KILL signal. Other signals give the process a chance to clean up after itself, but KILL does not. The operating system terminates the process and forcibly removes it from memory. Use this as a last resort.
You should not kill processes indiscriminately, especially if you don’t know what they’re doing. You may be shooting yourself in the foot.You may see other users entering numbers instead of names with kill; for example, kill -9 instead of
kill -KILL. This is because the kernel uses numbers to denote the different signals; you can use kill this way if you know the number of the signal that you want to send.
Background Processes
Normally, when you run a Unix command from the shell, you don’t get the shell prompt back until the program finishes executing. However, you can detach a process from the shell and put it in the “background” with the ampersand (&); this gives you the prompt back.
For example, if you have a large file that you need to decompress with gunzip and you want to do some other stuff while it’s running, run a command like this one:
$ gunzip file.gz &
The shell should respond by printing the PID of the new background process, and the prompt should return immediately so that you can continue working.
The dark side of running background processes is that they may expect to work with the standard input (or worse, read directly from the terminal). If a program tries to read something from the standard input when it’s in the background, it can freeze (try fg to bring it back) or terminate. Also, if the program writes to the standard output or standard error, the output can appear in the terminal window with no regard for anything else running there, meaning that you can get unexpected output when you’re working on something else.The best way to make sure that a background process doesn’t bother you is to redirect its output (and possibly input)
If spurious output from background processes gets in your way, learn how to redraw the content of your terminal window. The bash shell and most full-screen interactive programs support CTRL-L to redraw the entire screen. If a program is reading from the standard input, CTRL-R usually redraws the current line, but pressing the wrong sequence at the wrong time can leave you in an even worse situation than before. For example, entering CTRL-R at the bash prompt puts you in reverse isearch mode (press ESC to exit).
Reference: How Linux Works: What Every Superuser Should Know by Brian Ward
Discover more from Embedded for All
Subscribe to get the latest posts sent to your email.
Embedded for All 