Moving to Linux: Kiss the Blue Screen of Death Goodbye!
You are going to hear a lot about processes, process status, monitoring processes, or killing processes. Reducing the whole discussion to its simplest form, all you have to remember is that any command you run is a process. Processes are also sometimes referred to as jobs. Question: So what constitutes a process? Answer: Everything. The session program that executes your typed commands (the shell) is a process. The tools I am using to write this chapter are creating several processes. Every terminal session you have open, every link to the Internet, every game you have running all these programs generate one or more processes on your system. In fact, there can be hundreds, even thousands, of processes running on your system at any given time. To see your own processes, try the following command: [root@testsys /root]# ps PID TTY TIME CMD 12293 pts/5 00:00:00 login 12316 pts/5 00:00:00 su 12317 pts/5 00:00:00 bash 12340 pts/5 00:00:00 ps
For a bit more detail, try using the u option. This will show all processes owned by you that currently have a controlling terminal. Even if you are running as root, you will not see system processes in this view. If you add the a option to that, you'll see all the processes running on that terminal in this case, revealing the subshell that did the su to root: [root@testsys /root]# ps au USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 12293 0.0 0.4 2312 1196 pts/5 S 21:23 0:00 login -- mgagne mgagne 12294 0.0 0.3 1732 976 pts/5 S 21:23 0:00 -bash root 12316 0.0 0.3 2156 952 pts/5 S 21:23 0:00 su - root root 12317 0.0 0.3 1736 980 pts/5 S 21:23 0:00 -bash root 12342 0.0 0.2 2400 768 pts/5 R 21:24 0:00 ps au The most common thing someone will do is add an x option as well. This will show you all processes, controlled by your terminal or not, as well as those of other users. The administrator will also want to know about the l option, which stands for "long." It is particularly useful because it shows the parent process of every process, because every process has another process that launched (or spawned) it. This is the parent process of the process ID. In sysadmin short form, this is the PPID of the PID. When your system starts up, the first process is called init. It is the master process and the superparent of every process that will come until such time as the system is rebooted. Try this incarnation of the ps command for an interesting view of your system: [root@testsys /root]# ps alxww | more F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 100 0 1 0 0 0 1120 120 134005 S ? 0:07 init [3] 040 0 2 1 0 0 0 0 12d42b SW ? 0:00 [kflushd] 040 0 3 1 0 0 0 0 12d4a0 SW ? 0:03 [kupdate] 040 0 4 1 0 0 0 0 123282 SW ? 0:00 [kpiod] 040 0 5 1 0 0 0 0 126896 SW ? 0:03 [kswapd] 140 1 336 1 0 0 1212 0 134005 SW ? 0:00 [portmap] 040 0 350 1 0 0 0 0 1ad198 SW ? 0:00 [lockd] 040 0 351 350 0 0 0 0 1aa906 SW ? 0:00 [rpciod] Again, this is a partial listing. You noticed, of course, that I threw a couple of new flags in there. The double w, or ww, displays each process's command-line options. A single w TRuncates the options at a half a line. The columns you see there tell you a little bit more about each process. The F field indicates the process flag. A 040 in that position indicates a process that forked but didn't exec, whereas a 140 means the same, but that superuser privileges were used to start the process. The UID field represents the user ID, while PID and PPID are, respectively, the process ID and parent process ID that I covered earlier. PRI and NI (priority and nice number, respectively) will feature later when I discuss performance issues. In fact, there are quite a number of information flags for the ps command. Every system administrator should take some time to read the main page. More important, play with the command and the various flags. You will be enlightened. Forests and Trees
With all the information displayed through ps, you can be forgiven if your head is starting to hurt a bit. It is a little like trying to see the forest but being overwhelmed by the sheer number of trees. And yet, all these processes are linked in some way. Luckily, your stock Linux distribution contains tools to make this easier. One of them is called pstree. Here's a sample of what you get by simply typing the command and pressing Enter: init-+-aio/0 |-atd |-bonobo-activati |-crond |-cupsd |-devfsd |-events/0 |-gconfd-2 |-httpd2-+-advxsplitlogfil | `-5*[httpd2] |-ifplugd |-kalarmd |-kblockd/0 |-kdeinit-+-artsd | |-karm | |-12*[kdeinit] | |-kdeinit---bash | |-kdeinit-+-aspell | | `-2*[gs] | |-kdeinit---bash---pstree | `-soffice.bin |-12*[kdeinit] |-kdeinit---perl |-kdesud |-kicker |-klogd |-knotes |-kontact |-kopete |-lockd |-login---bash---startx---xinit-+-X
This is only a partial listing, but notice that everything on the system stems from one super, ancestral process called init. Somewhere under there, I have a login that spawns a shell. From that shell, I start an X window session, which spawns a WindowMaker application. Even so, GNOME and KDE applications are in there as well. If you want a similar output but in somewhat more detail, you can go back to your old friend, the ps command. Try the f flag, which in this case stands for "forest," as in forest view. The following output is the result of my running "ps axf". Once again, this is a partial listing, but unlike the pstree listing, you also get process IDs, running states, and so on. $ ps axf 1894 tty6 S 0:00 /sbin/mingetty tty6 2513 ? S 0:00 /sbin/ifplugd -w -b -i eth1 3099 ? S 0:00 login -- mgagne 3169 tty1 S 0:00 \_ -bash 3228 tty1 S 0:00 \_ /bin/sh /usr/X11R6/bin/startx 3241 tty1 S 0:00 \_ xinit /home/mgagne/.xinitrc -- -deferglyp 3242 ? S 65:16 \_ /etc/X11/X :0 -deferglyphs 16 3247 tty1 S 0:00 \_ /bin/sh /usr/bin/startkde 3256 tty1 S 0:13 \_ magicdev 3304 tty1 S 0:00 \_ kwrapper ksmserver 3270 tty1 S 0:00 /usr/lib/gconfd-2 13 3273 ? S 0:01 kdeinit: Running... 3278 ? S 0:01 \_ kdeinit: klauncher 3300 ?
In the Linux world, you can find a number of programs devoted to deciphering those numbers, thereby making it possible to find out what processes are doing and how much time and resources they are using to do it, making it possible to manage the resultant information. |