rel="shortcut icon" href="http://cookingwithlinux.com/misc/favicon.ico" type="image/vnd.microsoft.icon" /> Mastering The Linux Shell - Processes | Cooking With Linux
Back to Top

Mastering The Linux Shell - Processes

So what constitutes a process on your Linux system?  The short answer is : Everything

In your long and illustrious career as Linux gurus, you are going to hear a lot about processes, process status, monitoring processes, or even killing processes. Gasp! Reducing the whole discussion to its simplest form, all you have to remember is that any command we run is a process.  Processes are also sometimes referred to as jobs. 

The session program which executes our typed commands (the shell, or terminal if you prefer) is a process.  The tools I am using to write this article such as my desktop, the browser, the server somewhere out on the internet . . . these are creating several processes and sub-processes.  Every terminal session you have open, every link to the Internet, every game you have running, the little clock in the corner; all these programs will 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.

fullhouse ~ # ps

  PID TTY          TIME CMD
14759 pts/4    00:00:00 sudo
14760 pts/4    00:00:00 bash
14803 pts/4    00:00:00 ps

For a bit more detail, try using the “u” option to the ps command.  This will show all processes owned by you that currently have a controlling terminal.   Even if you were running as root, you would 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 sub-shell that did the su to root.

fullhouse ~ # ps au

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1534  0.0  0.0  19976   972 tty6     Ss+  Apr09   0:00 /sbin/getty -8 
root      1689  6.0  1.0 143544 59984 tty8     Rs+  Apr09 161:43 /usr/bin/X :0 v
root      1788  0.0  0.0  11756   816 tty1     Ss+  Apr09   0:00 /sbin/getty -8 
mgagne    3254  0.0  0.0  18260  3508 pts/1    Ss+  Apr09   0:00 /bin/bash
mgagne    6770  0.0  0.0  18132  3264 pts/2    Ss   Apr09   0:00 /bin/bash
root     14759  0.0  0.0  69176  2256 pts/4    S    08:55   0:00 sudo -i
root     14760  0.0  0.0  18100  3232 pts/4    S    08:55   0:00 -bash
root     14816  0.0  0.0  14380  1156 pts/4    R+   08:57   0:00 ps au

The most common thing someone will do is add an “x” option as well.  This will show you all processes, whether controlled by your terminal or not, as well as those of other users.  The administrator will also want to know about the “l” option.  This stands for “long” and is particularly useful because it shows the parent process of every process.   That’s 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 super-parent of every process that will come until such a time as the system is rebooted.   Try this incarnation of the ps command for an interesting view of your system. 

fullhouse ~ # ps alxww | more

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0     1     0  20   0  24580  2584 poll_s Ss   ?          0:01 /sbin/init
1     0     2     0  20   0      0     0 kthrea S    ?          0:00 [kthreadd]
1     0     3     2  20   0      0     0 run_ks S    ?          1:23 [ksoftirqd/0]
1     0     5     2   0 -20      0     0 worker S<   ?          0:00 [kworker/0:0H]
1     0     7     2   0 -20      0     0 worker S<   ?          0:00 [kworker/u:0H]
1     0     8     2 -100  -      0     0 cpu_st S    ?          0:00 [migration/0]
1     0     9     2 -100  -      0     0 watchd S    ?          0:00 [watchdog/0]
1     0    44     2   0 -20      0     0 rescue S<   ?          0:00 [crypto]
1     0    53     2   0 -20      0     0 rescue S<   ?          0:00 [kthrotld]
1     0    57     2  20   0      0     0 worker S    ?          1:12 [kworker/1:1]
1     0    58     2  20   0      0     0 scsi_e S    ?          0:00 [scsi_eh_0]

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” will display each process’ command line options.  A single “w” will truncate the options at a half a line.  

The columns you see there tell us 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 super-user privileges were used to start the process.  The UID field represents the user ID while PID and PPID are the process and parent process ID that we talked about earlier.  PRI and NI (priority and nice number) will feature later when I cover performance issues in a later article.  In fact, there are quite number of information flags for the ps command.  Every person who administers a system should take some time to read the man page.  More importantly, 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 ways.  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 hitting ENTER.

fullhouse ~ # pstree -A

init-+-GoogleTalkPlugi---5*[{GoogleTalkPlugi}]
     |-NetworkManager-+-2*[dhclient]
     |                |-dnsmasq
     |                `-2*[{NetworkManager}]
     |-acpid
     |-akonadi_control-+-5*[akonadi_agent_l---{akonadi_agent_l}]
     |                 |-akonadi_archive
     |                 |-akonadi_imap_re
     |                 |-akonadi_maildis
     |                 |-akonadi_mailfil
     |                 |-akonadi_nepomuk---{akonadi_nepomuk}
     |                 |-akonadiserver-+-mysqld---36*[{mysqld}]
     |                 |               `-22*[{akonadiserver}]
     |                 `-3*[{akonadi_control}]
     |-at-spi-bus-laun-+-dbus-daemon
     |                 `-3*[{at-spi-bus-laun}]
     |-at-spi2-registr---{at-spi2-registr}
     |-atd
     |-avahi-daemon---avahi-daemon
     |-bluetoothd
     |-colord---2*[{colord}]
     |-console-kit-dae---64*[{console-kit-dae}]
     |-cron
     |-cupsd
     |-2*[dbus-daemon]
     |-dbus-launch
     |-dnsmasq
     |-dropbox---18*[{dropbox}]
     |-gconfd-2
     |-6*[getty]
     |-gvfsd---{gvfsd}
     |-gvfsd-fuse---4*[{gvfsd-fuse}]
     |-irqbalance
     |-kactivitymanage---6*[{kactivitymanage}]

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 from which spawns my desktop environment and so on and so on. There can be applications from different desktop environments under that. I'm running KDE Plasma but I also have GNOME applications in my mix. Notice that I had a "-A" flag on the pstree comment. This makes the output ASCII friently so I can use it in a graphical terminal session. Or on a printout. To see a more *ahem* graphical version of the comman, look at the screenshot image that introduces this post. It's the same command, minus the ASCII flag.

If you want a similar output, but in somewhat more detail, we can go back to our old friend, the ps command.  Try the “f” flag which, in this case, stands for “forest”, as in forest view.    Once again, this is a partial listing, but unlike the pstree listing, you also get process IDs, running states, and so on. 

[root@testsys /root]# ps axf

    1 ?        Ss     0:01 /sbin/init
  390 ?        S      0:00 upstart-udev-bridge --daemon
  392 ?        Ss     0:00 /sbin/udevd --daemon
  757 ?        S      0:00  \_ /sbin/udevd --daemon
 2557 ?        S      0:00  \_ /sbin/udevd --daemon
  593 ?        Ss     0:00 /usr/sbin/sshd -D
  876 ?        Sl     0:12 rsyslogd -c5
  913 ?        S      0:00 upstart-socket-bridge --daemon
  919 ?        Ss     0:01 smbd -F
 1073 ?        S      0:00  \_ smbd -F
15499 ?        S      0:00  \_ smbd -F
15500 ?        S      0:00  \_ smbd -F
 1027 ?        Ss     0:12 dbus-daemon --system --fork
 1039 ?        Ss     0:00 /usr/sbin/modem-manager
 1042 ?        Ss     0:00 /usr/sbin/bluetoothd
 1058 ?        Ss     0:01 /usr/sbin/cupsd -F
 1062 ?        S      0:09 avahi-daemon: running [fullhouse.local]
 1063 ?        S      0:00  \_ avahi-daemon: chroot helper 1152 ?        Ss     0:04 /sbin/wpa_supplicant -B -P /run/sendsigs.omit.d/wpasupplic
 1397 ?        Ss     0:05 nmbd -D
 1414 ?        Ss     0:00 /usr/sbin/winbindd -F
 1447 ?        S      0:00  \_ /usr/sbin/winbindd -F
 1514 tty4     Ss+    0:00 /sbin/getty -8 38400 tty4
 1519 tty5     Ss+    0:00 /sbin/getty -8 38400 tty5
 1529 tty2     Ss+    0:00 /sbin/getty -8 38400 tty2
 1531 tty3     Ss+    0:00 /sbin/getty -8 38400 tty3
 1532 ?        Ss     0:00 kdm
 1689 tty8     Rs+  165:09  \_ /usr/bin/X :0 vt8 -br -nolisten tcp -auth /var/run/xau
 1911 ?        S      0:00  \_ -:0
 2043 ?        Ss     0:00      \_ /bin/sh /usr/bin/startkde
 2111 ?        Ss     0:00          \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit
 2315 ?        S      0:00          \_ kwrapper4 ksmserver
 1534 tty6     Ss+    0:00 /sbin/getty -8 38400 tty6

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, how much  time and resources they are using to do it, and making it possible to manage the resultant information.

Performance is a topic I sometimes refer to as the Holy Grail because as system administrators, it is invariably what we are forever searching for.  Despite having faster machines with more processor, more memory, and more disk than some admin 20 years ago could have ever dreamed of, we still manage to drive that super fast mega-machine into the ground. How do we extract just that little bit more from our machines?  How do we make them faster?  Stronger?  These are such important questions that will devote another article to the subject, but on another day. 

Interrupting, suspending, and restarting processes

Once a day or so, I invariably start a process that I think is going to take more than a few seconds.   It will be something like this : parsing a large log file, scanning for some text, extracting something else, sorting the output, and finally sending the whole thing to a file.  All very ad hoc in terms of reporting.  The trouble is this.  Two and a half minutes have gone by and I am starting to get a little impatient.   Had I thought that the process would take a while, I might have started it in the background. If I was running on my graphical desktop, I'd just start another terminal window, but maybe I'm logged in at the console. Text only, for real this time. 

When you start a process (by typing a command name and hitting ENTER), you normally start that process in the foreground.   In other words, you terminal is still controlling the process and the cursor sits there at the end of the line until the process completes.  At that point, it returns to the command or shell prompt.  For most (not all) processes, you can run things in the background, thus immediately freeing up your command line for the next task.   You do that by adding an ampersand to the end of the command before you hit ENTER.

# sh long_process &

Unfortunately, I’ve already confessed to you that I wasn’t thinking that far ahead and now I am sitting here looking at a flashing cursor wondering whether I did something wrong and just how long this thing will take.  Now, I don’t want to end the process, but I wouldn’t mind being able to temporarily pause it so I can have a look at its output, then decide whether I want to continue.  As it turns out, you can do precisely that with a running process by using the Control-Z key sequence. 

# sh long_process
Ctrl-Z
[1]+  Stopped                 sh long_process

The process is now suspended.  In fact, if you were to do a “ps ax” and you looked for “long_process”, you would see this.

11091 ?        S      0:00 kdeinit: Running...
11127 tty1     S      0:00 rxvt -bg black -fg white -fn fixed
11128 pts/0    S      0:00 bash
11139 pts/0    S      0:00 ssh -l www-date mywebsite
11177 ?        S      0:00 smbd -D
11178 ?        S      0:00 smbd -D
11219 pts/2    T      0:01 sh long_process

That “S” you see in the third column of most of these processes means they are sleeping.  Yes, it's true; at any given moment or snapshot of your system, almost every single process will be sleeping and a small handful will show up with an “R” to indicate that they are currently running or runnable, sometimes referred to as being in the run queue.   The “T” you see beside our suspended process means that it is traced, or suspended. 

Two other states you might see processes in are “D” and “Z”.  The “D” means that your process is in an uninterruptible sleep and it is likely to stay that way (usually not a good sign).  The “Z” refers to a process that has gone zombie (and possibly that the zombie apocalypse is near).  It may as well be dead and probably will be just as soon as someone gets that message across. There's a command called "jobs", which will list the jobs you have running in the background, as well as the status of those jobs. 

$ jobs
[1]-  Running                 Eterm &
[2]+  Stopped                 xterm

Getting back to our suspended process, we have a few choices.  We could just restart it from where it left off by typing “fg” at the shell prompt.  In other words, continue the process in the foreground.  The second option is to type “bg” which tells the system (you guessed it) to run the suspended process in the background.  If we were to do that, the process would restart with an ampersand at the end of the command just as we did earlier.

[root@testsys /root]# bg
[1]+ sh long_process &

Our other option is to terminate the process, or kill it. As exciting as killing processes might sound and as ready as you might be to unleash your process killing prowess on those unsuspecting jobs, this is where I leave it for today. That's because there's a lot more to killing processes than just killing them. If you know what I mean. Sort of. Anyhow, I'll explain on Monday. If you wish to comment, please do so here on Google Plus or here on Facebook. Remember that you can also follow the action on CookingWithLinux.com where it's all Linux, all the time; except for the occasional wine review. Also, make sure you sign up for the mailing list over here so that you're always on top of what you want to be on top of.  Until next time . . .

A votre santé! Bon appétit!

ABOUT THE AUTHOR

Comments

The Original Cooking with Linux
 
  • The portal is active, but I can only keep it open for a few more seconds. You have to cross, and cross quickly! 12 hours 30 min ago
  • RT @RockyMntnMike: Fundamentalists perverting religion for political purposes, photographing themselves brandishing automatic weapons. But … 16 hours 41 min ago
  • Take it from me, black is the new black. 1 day 4 hours ago
  • Occulus Rift? #Minecraft? I think I'm starting to see what #Microsoft is up to. 1 day 8 hours ago
  • One religion's innocents is another's 'condemned to burn in Hell forever'. If your religion believes some are damned, it condones violence. 2 days 2 hours ago