I've heard that ps can do some really neat stuff. Care to elaborate?
I’ve heard that ps can do some really neat stuff. Care to elaborate?
This question presents us with a good excuse to focus on managing processes and getting to know the simple commands that help you get in touch with your system. Almost all of these are applications that make use of the data the kernel places into userland via /proc. The functions named are commonly found in the procps, or ps packages, and come as standard tools on all Linux distributions.
Let’s start with the ps command, which gives you information about the processes on your system. For something so incredibly useful, ps is often misunderstood and underrated. It will list all processes currently in memory on your machine, including all running kernel, user, and daemon processes. It functions by taking information from the kernel via /proc. This information is then displayed in the format requested.
For example, you can get ps to display process trees (as opposed to its normal output) — that is, a branch diagram of which processes have spawned other processes. This is demonstrated with the psaxwf command, as shown in Figure One.
Figure One: ASCII-art Tree Display of Processes Created by ps
110 ? S 0:01 /usr/local/sbin/sshd
10057 ? S 0:01 \_ /usr/local/sbin/sshd
10059 pts/0 S 0:00 \_ -bash
10070 pts/0 RN 11:45 \_ ./setiathome
10092 pts/0 S 0:00 \_ screen
10093 ? S 0:01 \_ SCREEN
10094 pts/1 S 0:00 \_ /bin/bash
10096 pts/1 S 0:00 | \_ man top
From this diagram, it’s possible to see that my shell server’s ssh daemon has spawned a copy of itself to handle my incoming connection. That daemon, upon my successful login, has gone on to spawn a copy of my preferred shell -bash. From this, I’ve started (and backgrounded) a copy of setiathome before launching screen and starting man to find better words for describing top.
By typing psaxwf, we ask ps to display (a)ll processes on a terminal, even those without a controlling tty (x), (w)ide, in a (f)orest (branch-tree) style. However, this is far from the limit of what ps can do. Take for example the (r)unning switch. This switch can help you discover the software causing late night hard drive activity, as it will give a list of processes that are in the middle of being executed. If you are like me, setiathome will be perpetually active, and some other processes, such as netscape, will also be listed as using CPU cycles.
There are a bunch of other modifiers that you can use to edit how ps hands you data. I’d strongly recommend man ps to catch up on some of the finer points of the application. It is far more robust than many people give it credit for.
I’m convinced that ps is cool, but there’s a problem. Whenever I do a ps aux, it cuts off at the right of the screen, and I can’t see the whole output!
This problem occurs because psaux natively only pans out to 80 characters, irrespective of screen width. The way to solve this problem is to add a w to your command line. For example, psauxw will cause ps’s output to extend all the way out to the current screen width. Anything beyond this will be wrapped onto the next line — but at least you’ll be able to see it.
Isn’t there a real-time way of seeing all this stuff without having to keep typing ps?
There sure is — top. According to the man page, top “provides an ongoing look at processor activity in real time.” Basically, it outputs a human-friendly view of all applications currently in memory, irrespective of state. An example of top’s output is shown in Figure Two.
Figure Two: Excerpt of a top Output
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
10070 q 15 1 14860 14M 264 R N 0 98.4 31.8 66:39 setiathome
10254 q 2 0 1024 1024 844 R 0 1.1 2.1 0:05 top
10057 root 0 0 1012 1012 696 S 0 0.1 2.1 0:02 sshd
10093 root 0 0 1028 1028 840 R 0 0.1 2.2 0:02 screen
1 root 0 0 60 52 40 S 0 0.0 0.1 0:09 init
Unlike ps,top automatically scales to fit whatever screen size you are using to view it. That is, if you stretch an xterm wide and long enough, you can get a full list of everything that is running on a system. This is incredibly handy if you want to see what processes are running on a number of machines by opening a few xterms on the same desktop, or if you are simply unhappy with where top cuts off its display of applications. However, just as with ps,top is more than just a pretty face.
top can be used for a myriad of simple system functions — in particular, killing a rogue process that is eating a lot of CPU time. In this case, take my setiathome client (shown in Figure Two) as a prime example. top makes it simple for root, or the user running the processes, to eliminate those that they no longer require. First, type k to kill a process, and then type in its process id (pid), as noted in the leftmost column. In the case of poor SETI, this is 10070. Next, you choose the signal to send to the process. Just hit enter again to accept the default termination signal. If the program just won’t die, try typing the number 9 to terminate the process with extreme prejudice. A caveat however — processes sent a kill-9 will not be able to catch the signal and will end prematurely, potentially losing data.
top also offers a secure mode, top s. In this mode, top will not be able to execute potentially dangerous commands. This is fantastic if you want to have it running on a separate (and insecure) terminal where you don’t want people killing processes and the like. To alter the speed with which the display is updated, simply press s while the program is running and enter a time in seconds — noting that the greater the number of updates, the more CPU-intensive top will become. Also of note is that top can accept fractions of seconds as a time delay between updates (e.g., .5 seconds). This does little but waste CPU, but is fun to watch for a while (assuming a very slow day at the office).
What other neat tools are available?
There are a number of simple tools available for viewing data that /proc makes available. One is vmstat. This displays averaged virtual memory statistics on I/O, memory, paging, CPU usage, and more. This is another incredibly useful tool — especially once you are accustomed to its output. Another old favorite of mine is uptime, which simply displays how long it’s been since the machine booted and the average load over the time that it has been awake.
Also useful is free, which is a very brief overview of the system’s memory utilization. free, just like vmstat, may continually poll to output information on a timer delay. Simply execute free -s [time in seconds] to have a continuously updated view of memory resources scroll up the screen. You can check out the man pages on all of these programs for more information.
Does all this mean it’s dangerous to go into /proc without the help of these tools?
Yes and no. If you’re just interested in viewing a few files in the /proc directory, that should be no problem at all. However, if you intend to echo values into files in /proc as root, beware; you can do some serious harm. Some of the files in /proc are there for user friendliness and status output, but most serve a very practical purpose.
For a quick introduction, take a look at /proc/filesystems. This file lists the filesystem types that the currently running kernel is capable of interpreting, and therefore, is capable of mounting. Unsure about whether you can mount that VFAT partition? Just cat /proc /filesystems to find out.
Also handy is /proc/cpuinfo for learning what the operating system has been able to derive about your CPU. You might also want to check out /proc/meminfo for details about the state of the server’s RAM (similar to the program free, listed above). These are all files you may cat to the screen without fear of wayward system functions. However, as previously stated, clear distinctions must be drawn between editing and reading.
Many kernel tweaks are available by directly editing the values stored in /proc. These include TCP packet settings, I/O parameters, IP forwarding procedure, and many more. This can be a minefield for the inexperienced, so be sure to read documentation closely before editing any values. In short, don’t be afraid to investigate the operating system by poking around a little while reading a lot.
Be sure to fire up your favorite search engine and seek out some documentation; you can check out /usr/ src/linux/Documentation for more details if you start to get lost. Both tasks can be frustrating, but they are often invaluable for learning how everything fits together.
The bottom line is that monitoring system activity is sooner or later going to be necessary for any system owner or administrator. The tools we have discussed here provide a somewhat human-friendly means for looking at what’s running and how the system is performing. Mastery of these commands will prove invaluable for your continued journey through the world of Linux and should be studied closely.
Quentin Cregan is a tech and security consultant and sometime student hailing from Australia. He can be reached at firstname.lastname@example.org.