Viewing Running Processes | Hacking Ubuntu: Serious Hacks Mods and Customizations (ExtremeTech)

The only things that consume systems resources are running processes. If your computer seems to be running slower than normal, then it is probably due to some process that is either misbehaving or consuming more resources than you have available.

There are a couple of easy ways to find out what is running. From the command line, you can use ps and top to show applications, dependencies, and resources. For example, ps -ef shows every (-e) running process in a full (-f) detailed list (see Listing 7-1). The columns show the user who runs the process (UID), the process ID (PID), the parent process ID (PPID) who spawned this process, as well as when the process was started, how long it has been running, and of course, the process itself.

Listing 7-1: Sample Listing of Running Processes from ps -ef

 UID        PID  PPID  C STIME TTY          TIME CMD root         1     0  0 Sep28 ?        00:00:01 init [2] root         2     1  0 Sep28 ?        00:00:00 [migration/0] root         3     1  0 Sep28 ?        00:00:00 [ksoftirqd/0] root         4     1  0 Sep28 ?        00:00:00 [watchdog/0] root      2406     1  0 Sep28 ?        00:00:00 [kjournald] root      2652     1  0 Sep28 ?        00:00:00 /sbin/udevd --daemon root      3532     1  0 Sep28 ?        00:00:00 [shpchpd_event] root      4219     1  0 Sep28 ?        00:00:00 [kjournald] daemon    4370     1  0 Sep28 ?        00:00:00 /sbin/portmap root      4686     1  0 Sep28 ?        00:00:00 /usr/sbin/acpid -c /etc/acpi/eve nts -s /var/run/acpid.socket root      4857     1  0 Sep28 ?        00:00:00 /bin/dd bs 1 if /proc/kmsg of /v ar/run/klogd/kmsg klog      4859     1  0 Sep28 ?        00:00:00 /sbin/klogd -P /var/run/klogd/km sg root      5174     1  0 Sep28 ?        00:00:00 /usr/sbin/gdm hplip     5213     1  0 Sep28 ?        00:00:00 /usr/sbin/hpiod hplip     5217     1  0 Sep28 ?        00:00:00 python /usr/sbin/hpssd nobody    5303     1  0 Sep28 ?        00:00:00 /usr/sbin/danted -D nobody    5304  5303  0 Sep28 ?        00:00:00 /usr/sbin/danted -D nobody    5306  5303  0 Sep28 ?        00:00:00 /usr/sbin/danted -D nobody    5308  5303  0 Sep28 ?        00:00:00 /usr/sbin/danted -D

All in the Family

There are two main branches of Unix: BSD and System V. BSD is the older branch, and provides a standard that is used by operating systems such as FreeBSD, OpenBSD, SunOS, and Mac OS X. The BSD standard defines process management, device driver naming conventions, and system directory layouts. The younger branch, System V (pronounced "System Five"), includes operating systems like HP- UX, AIX, Solaris, and IRIX. System V follows the POSIX standards and differs slightly from the BSD family. For example, BSD places all device drivers in /dev-this directory may contain hundreds of devices. POSIX defines subdirectories in /dev, so all disks will be in /dev/disk (or /dev/dsk, /dev/rdsk, and so on) and all network drivers are in /dev/net. This makes /dev a cleaner directory.

These differences also show up in the ps command. Typing ps -ef on System V generates similar output to ps -aux on BSD.

Not every operating system is strictly in the BSD or System V camp. Linux, for example, supports both BSD and POSIX. Under Linux, hard drives are usually listed in /dev/ (for example, /dev/hda and /dev/hdb) and in /dev/disk/. There are a few places where the standards conflict (for example, what goes in specific directories); in these cases, the Linux selection seems almost arbitrary. For example, the /sbin directory under BSD contains system binaries. Under POSIX, they contain statically linked executables. Under Linux, they contain both.

The Linux ps command actually supports two different output formats: BSD and POSIX. Options that begin with a dash (for example, -e, -f, or combined as -ef) follow the POSIX standard. Without the dash (for example, ps aux) ps acts like BSD.

The top command shows all running processes and can order them by memory or CPU resource usage. Unlike ps, which provides a single snapshot of the currently running applications, top refreshes every few seconds to show you what is actively running. Processes that are spawned but not active will appear further down the top listing. You can interact with top in order to change the refresh rate (type s and then enter the refresh rate in seconds) or ordering (use < and > to select the order-by column). You can also press h to see a full list of the supported commands.

The graphical System Monitor (System Administration System Monitor) also enables you to see the list of running processes (see Figure 7-1).

image from book
Figure 7-1: The System Monitor showing processes

Killing Processes

Under Linux, there are a maximum of 65,536 different PIDs-you cannot have more than 65,536 processes running at once. Under Ubuntu, the default maximum is 32,768 PIDs. (See "Tuning Kernel Parameters" later in this chapter; this parameter's name is kernel.pid_max.) Any new process is assigned the next available PID. As a result, it is possible to have a new process start with a lower PID than some older process. You can use the PID to kill processes using the kill command. For example to kill PID 123 use kill 123. The kill command can also be used to suspend processes (kill -STOP 123) and continue paused processes (kill -CONT 123). However, some processes do not die immediately.

Note

Technically, PIDs are handles to processes and not actual processes. A multi-threaded process may have one handle for all threads, or one handle per thread. It all depends on how the process creates the threads.

Every process is assigned a dynamic PID, but there are two exceptions: kernel and init. The kernel uses PID 0 and is not listed by ps, top, or the System Monitor. You cannot kill the kernel (with the kill command). The init process (briefly discussed in Chapter 1) is the master parent process. Every process needs a running parent (PPID) to receive return codes and status from children. If a process' parent dies, then init becomes the parent.

Warning

While you can kill init (sudo kill -9 1), you don't want to do this! Killing init will eventually crash the system since init is used to clean up dead processes.

Killing a process kills it once; the kill signal does nothing to prevent the process from being started up again. In addition, there are some processes that cannot be killed.

Zombies-When a process dies, it returns an error code to its parent (PPID). A dead PID whose return code has not yet been received by its parent becomes a zombie. Zombies take up no CPU, but do take up a PID. For programmers, calling the wait() function retrieves return codes and kills zombies. In contrast, sending a kill signal to a zombie does nothing since the process is already dead.
I/O Bound-A process that is blocked on a kernel driver call may not process the kill signal until the kernel call returns. This is usually seen with network file system calls (NFS) when the network is down or on disk I/O when the drive is bad. For example, if you are using an NFS mounted directory and run ls, the command may hang if the network mount is bad. Sending a kill signal to the ls process will not immediately kill it. I've also experienced these hangs when using dd to copy a disk that was in the middle of a head-crash.
Interception-Some kill signals can be intercepted by applications. For example, programs can intercept the default signal (kill, kill -15, or kill -TERM). This is usually done so the program can clean up before exiting. Unfortunately, some programs don't die immediately. Other kill signals, such as kill -KILL or kill -9, cannot be intercepted.

Tip

If you really want to kill a process, first use kill PID (e.g., kill 1234). This sends a TERM signal and allows well-behaved processes to clean up resources. If that does not get the result you want, try kill -1 PID. This sends a hang-up signal, telling the process that the terminal died. This signal is usually only intercepted by well-behaved processes; other processes just die. If that does not kill it, then using kill -9 PID. This is a true kill signal and cannot be intercepted by the process. (Kill -9 always reminds me of Yosemite Sam shouting, "When I say whoa, I mean WHOA!")

Signals: Night of the Living Dead

Each signal is associated with a long name, short name, and number. The most common signals are:

SIGHUP, HUP, 1-This is a hang-up signal that is sent to processes when the terminal dies.
SIGINT, INT, 2-This is an interrupt signal. It is sent when the user presses Ctrl+C.
SIGKILL, KILL, 9-The true kill signal. This cannot be intercepted and causes immediate death.
SIGTERM, TERM, 15-This is a request to terminate signal and is the default signal sent by the kill command. Unlike KILL, TERM can be intercepted by the application.
SIGSTOP, STOP, 19-This signal stops the process but does not terminate it. This is sent when you press Ctrl+Z to halt the current process.
SIGCONT, CONT, 18-This resumes a process that is suspended by SIGSTOP. For a paused process at the command line (Ctrl+Z), typing fg will continue the process in the foreground and bg will continue the process in the background.
SIGCHLD, CHLD, 17-Programmers who write spawning applications use this signal. CHLD is sent to the parent whenever any child dies.

The full list of signals is in the man page for signal (man 7 signal). Any of these representations can be used by the kill command. Typing kill -9 1234 is the same as kill -KILL 1234 and kill -SIGKILL 1234.

Signals are flags; they are not queued up. If you send a dozen TERM signals to a process before the process can handle them, then the process will only receive one TERM signal. Similarly, if a program spawns six children and all die at once, then the parent may only receive one CHLD signal. If the parent fails to check for other dead children, then the remaining children could become zombies.

Killing All Processes

Every developer I know has, at one time or another, created a spawning nightmare. Sometimes killing a process only makes another process spawn. Since spawning happens faster than a user can run ps and kill, you won't be able to kill all of the processes. Fortunately, there are a couple of options.

Kill by name-If all the processes have the same name, you can kill them all at once using killall. For example, if my process is called mustdie, then I can use killall -9 mustdie to end all running instances of it.

Kill all user processes-There is a special kill command that will end all processes that you have permission to kill: kill -9 -1. As a user, this kills all of your processes, including your graphical display and terminals. But it will definitely kill any spawning loops you may have running.

Note

Technically, the process ID -1 is a special case for the kill command. This means kill everything except the kill command (don't kill yourself) and init (don't kill the default parent).

Warning

Never use kill -9 -1 as root! This will kill every process-including shells and necessary system applications. This will crash your system before you can take you finger off the Enter key. If you need to kill all processes as root, use the power button or use the reboot or shutdown commands-don't use kill -9 -1.

Stop processes-Infinite spawning loops usually happen because one process detects the death of another process. Instead of killing the processes, use the stop signal: kill -STOP PID or killall -STOP Name. This will prevent further spawning and enable you to kill all the sleeping processes without them re-spawning.