Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Unix ps command and Unix system tuning

In modern Unixes ps is implemented using /proc pseudo filesystem. See also top command which is a simple monitoring tool for running process. In most Posix compaible Unixes ps commonly is used with the options -ef, where "-e" selects every process and "-f" chooses the "full" output format:

• -e print all processes.  Shows the command environment for each process. This is useful in a situation where a program works for one user but not for another, or on one machine but not on another.
  
• -f print full listing. Shows children descended from their parents in an ASCII art tree. I find this very useful when looking at problem processes. Use with the S option to see CPU information from children summed up with parents.

The ps command by default truncates output at 80 column. To avoid this problem and full invocation like you use -w option, for example

Another useful option is option -l

• -l long listing (more info than -f)

Meaning of full listing columns:

• S state
• PRI priority
• SZ total size (in 4096 byte pages) of the process
• RSS total resident size (in pages) of the process
• STIME starting time
• TIME cumulative execution time

ps with grep

Often ps is used with grep like in ps -ef | grep httpd There is a simple way to get rid of displaying additional line in the result of such command: make the first letter (actually any letter a class of symbols with square brackets. for example

ps | grep [h]ttpd

The essence of this trick is that brackets allow specify class of symbol which is out case contain a single symbol. But this notation prevent grep from picking up the line grep [h]ttpd as it does not contin the string httpd.  

Probably a better way to to create function to solve this problem See Unix Review Shell Corner PS-n-Grep — The Steroid Version

Actually pgrep -l  provides similar functionality.

BSD versiion of ps

Common options:

• -a print all processes involving terminals
• -e print environment and arguments
• -l long listing
• -u print user information
• -x include processes with no terminals

Meaning of user information columns:

• %CPU percentage use of CPU
• SZ total size (in 1024 byte pages) of the process
• RSS total resident size (in pages) of the process
• STAT state of the process
• TIME time, including both user and system time

Old News ;-)

Show the entire line with the linux-unix ps command

Problem:

One thing that always drove me crazy was not being able to get the full listing from the ps command. For example when doing ps -elf it will cut off the command column. Even dumping it to file is no help, as the command column will get cut off if it goes beyond the 80 char width.

Solution:

Use the width switch:
ps -elf --width 500 | grep java.*encode
-o switch is handy too
ps -u apache --width 1000 -o "%p|%a" | grep java.*# the -u switch only shows processes with the user of apache
Here is are a list of other column descriptors that can be used with the -o switch

%C pcpu %CPU
%G group GROUP
%P ppid PPID
%U user USER %a args COMMAND
%c comm COMMAND
%g rgroup RGROUP
%n nice NI
%p pid PID
%r pgid PGID
%t etime ELAPSED
%u ruser RUSER
%x time TIME
%y tty TTY
%z vsz VSZ

Unix Review Shell Corner PS-n-Grep — The Steroid Version by Ed Schaefer

How many of us check the Unix process table using the ps command and pipe it to grep? This month, Bob Orlando presents Perl and awk scripts that add intelligence to this process.

PS-n-Grep: The Steroid Version

(or "What Is The Most Common Letter In The English Language And What Does It Have To Do With Shell Programming?")

by Bob Orlando

If you've worked in Unix for any length of time, you're probably familiar with psg or some such variant. Psg stands for "ps through grep" (essentially a ps query whose result is piped grep). It works and works well, but sometimes you need more than just a process string; sometimes you want the process string AND the process ID (PID) — separated. Oh yes, and since we're compiling a wish list here, how about the operation simply telling me how many processes match a given target string. I'll show how to do all of that — and do it without having to run multiple ps commands and filtering those results through several piped operations. To begin, let's take a quick look at psg.

Instead of typing "ps -your_options | grep", most folks simply alias psg to something like the following:

alias psg='/usr/bin/ps -eaf | grep -i'
alias psgw='/usr/ucb/ps -auxww | grep -i'

If you don't want to see the "grep" line itself in the output, then you have to do something like this:

psg()  { /usr/bin/ps -eaf   | grep -i "$@" | grep -v " grep -i" ; }
psgw() { /usr/ucb/ps -auxww | grep -i "$@" | grep -v " grep -i" ; }

In those two lines, we establish psg and psgw as functions. They behave just like aliases, but with some expanded capability. Essentially, the functions run their respective ps commands, selecting only those lines matching the string provided ("$@"). The "$@" (including the quotation marks) allows for embedded blanks as well as quotation marks themselves. The first grep -i filters out all but the desired string(s), while the second, grep -v excludes any result bearing the grep -i. Pretty basic stuff. Now for the steroids: PSWP and PSWA.

The PSWP and PSWA scripts described below (the first using Perl, the other awk) grew out of those common ps-n-grep aliases. The purpose of these scripts is to use the UCB ps -auxww command to list those processes in the process queue that match our target and to separate the result into:

1. A list of the PIDs
2. Full ps output strings
3. A count of matching PIDs indicated in our return status

Here's how the Perl version works.

PSWP

PSWP (PS -W via Perl) is a shell function that uses UCB ps -auxww to list processes in the process queue, displaying process lines matching our target string. Originally the function was needed for a script I was writing that needed to do the following: restart a critical process by first killing off any of the old processes that failed to terminate via the shutdown operation, call the standard startup script, and lastly, confirm that the restarted process was running by verifying that the expected processes were all found in the process queue.

UCB's ps was necessary because it provided a detailed (read "long") process string to ensure we could find exactly the target process we wanted with little chance of returning a false success (i.e., finding another process that had a similar but, therefore, less unique string). Further, when locating the target string, PSWP is careful to exclude itself, as well as any "vi" (an edit operation often responsible for falsely reporting a "found" ps string). I usually use awk for such ps interrogations (where the need is to return the PID as well as the ps string), but with the UCB ps returning 5,000+ bytes of data, awk's limited input buffer size made Perl the obvious choice — one that served me very well.

PSWP's modular design (written as a standalone function) was deliberate. I saw many potential situations where its capabilities would be helpful and allow for seamless integration into both Bourne and Korn scripts.

Sure enough, it wasn't long before I was tasked with writing yet another restart script. I was going to use PSWP, but this time the host on which the process would run was a stripped-down certification machine that lacked the space to install Perl (Dang! I hate it when that happens). It was back to awk.

PSWA

PSWA (PS -W via awk) is also a shell function that uses UCB ps -auxww to list processes in the process queue and display process lines matching our target string. (Does this sound like the movie "Groundhog Day"?) Awk is still a very powerful tool, and although it lacks the superset of string manipulation capabilities available in Perl, it is capable of performing some pretty complex pattern matching and selection operations.

To work around awk's input buffer limitation, I knew I had to play with the record separator (RS). For that I used the letter "e", the most common letter in the English language. (The "e" record separator is easily changed via the function's -r option.) As the most common letter in English, using it as the record separator allows the program to ingest all the data in byte-size chunks (bypassing awk's input buffer limitations). Once it encounters a new line, the byte-size pieces are reassembled into a single line for comparison against our target ps string.

As with PSWP, writing the program as a function makes it available for use in many other scripts. For even greater portability, both scripts, pswa.sh and pswp.sh, are written using Bourne syntax so they work equally well in Korn or BASH scripts and environments. To further facilitate this, I deliberately omitted any shell invocation (the she-bang or #!/usr/bin/sh). Thus, it runs seamlessly within the invoking shell. Also, to prevent needlessly loading the script, in case it is repeatedly sourced, the script checks to see whether it is already loaded before loading itself again. It does this by determining under which shell it is running and checking accordingly. Lastly, to provide a rudimentary level of variable scoping, function variables are prefixed with _PSW_ (i.e., $_PSW_rs).

In addition to the record separator option, -r, there is also an option for ignoring case (-i), when searching for the target ps string. This is especially handy for impromptu process queries. (See Example No. 9 below for assigning PSWA or PSWP in your .profile for case-insensitive queries.)

Both functions provide a list of process IDs via stdout, and a list of matching ps strings are delivered via stderr. Fulfilling our last "wish list" requirement, both PSWA and PSWP return the actual number of processes found in the return/exit status (see "EXIT STATUS below). The caller need only redirect/capture the desired output. The following examples show how.

Examples

In the examples that follow, I call PSWA, but you need only substitute PSWP to receive identical results.

After sourcing the script to load the function (i.e., . ./pswa.sh or . ./pswp.sh), you can run PSWA or PSWP as follows:

1. Find jsm-ruleseng in process queue. PIDs are displayed in stdout, while the actual ps strings are displayed via stderr:

          PSWA jsm-ruleseng
   

2. Find jsm-ruleseng, printing PIDs, discarding any ps line output by redirecting stderr to /dev/null:

          PSWA jsm-ruleseng 2> /dev/null
   

3. Find jsm-ruleseng assigning ps output (stderr) to $pss and redirecting pids (stdout) to /dev/null:

          pss=`PSWA -- "jsm-ruleseng" 2>&1 > /dev/null`
   

4. Find jsm-ruleseng assigning PID list to $pids and redirecting any ps line output to a file:

          pids=`PSWA -- "jsm-ruleseng" 2> /tmp/stderr`
   

5. Return only the number of processes found (see "Returns:" below):

          PSWA -- jsm-ruleseng > /dev/null 2>&1
          status=$?
   

6. Find -bg black -fg Green (note the "--" to end option processing before the string):

          PSWA -- -bg black -fg Green
   

7. Find -bg black -fg Green ignoring case:

          PSWA -i -- -bg black -fg Green
   

8. Find -bg black -fg Green using the second most frequently found letter in the English language:

          PSWA -r "t" -- -bg black -fg Green
          PSWA -r t -- -bg black -fg Green # Ditto
   
        +---------------------------------------------+
        | The -r option is unnecessary with PSWP and  |
        | therefore, not available therein.           |
        +---------------------------------------------+
   

9. Alias PSWA function as pswa so we can search the process queue, ignoring case:

          . ./pswa.sh # Source the PSWA function.
          pswa () {PSWA '-i' "$@" 2>&1 1> /dev/null ; }
   

   Again, calling PSWA in this fashion (as a function instead of an alias) makes alias functionality available regardless of shell.

Except for the -r, record separator option (example 8), command syntax for both PSWA and PSWP are identical.

Exit Status

PSWA and PSWP return the number of matching process lines in our status as follows:

0-253 = Actual number of processes found
254 = Indicates more than 253 processes found
255 = ERROR: Caller provided no target ps string

Testing

For testing these scripts, I wrote a simple psw_test.sh. Calling it as a background operation (psw_test.sh &) adds a job to the process queue that carries with it a 12,000+ byte long string you hope you'll never have to face in real life. Both PSWP and PSWA handled that process with equal ease.

Performance

Despite its expanded output capability, the Perl version still runs as quickly as the basic psg. For the dozen or so hosts on which I've run it, the timed result consistently returns in roughly half a second. Despite having four times the code, the awk function also runs very quickly — consistently in a single second. With the increasing availability of Perl, it is unlikely I'll need PSWA much longer. Still, writing the awk version was rewarding because I learned some very interesting things (such as the two most common letters in the English language).

For the past 25 years, Bob has been a Unix programmer, systems administrator, and DBA (Sybase and Oracle). In his free time, he heads the Je du-too School of Martial Arts (http://www.orlandokuntao.com/) in Denver, Colorado and is the author two books and three videos on martial arts.

Unix Simplicity Filtering the unix ps command

Now, suppose you are only interested in the process information
for "vi". You could do the following:
 

$ ps | grep vi
10ae 0535 0056 0c34 10ae (vi.exe) \unix\bin\vi.exe
1105 10ae 15cd 0000 2112 (/unix/bi)  -c ps | grep vi

The problem is that you also get the entry for the "grep" process itself.
There is a simple, elegant solution:
$ ps | grep [v]i
10ae 0535 0056 0c34 10ae (vi.exe) \unix\bin\vi.exe

In regular expressions, brackets contain either-or options. So "[sz]ys" would match "sys" or "zys". If only one character is in brackets, as in "[v]i", then the regular expression simplifies to "vi" upon execution.

Thus, in our case, "grep" is simply looking for "vi", but the "ps" entry for the "grep" contains the original "[v]i", so we prevent a match.

Hiding Passwords From UNIX ps Command

When running an sql script from unix, the unix ps (process status) command has a nasty habit of showing the Oracle userid and password of the sqlplus session.  To get around this problem, you can pipe the password into sqlplus instead of putting it in as part of the sqlplus command line (which is what shows up in the ps listing).  Below are examples of piping in the password (userid system, password systempw) for sqlplus, import, and export.  If you put these in a unix shell command file, such as myfile.shl, be sure to do a "chmod 700 myfile.shl" so that only your userid can see your Oracle passwords in that file!

echo systempw | sqlplus -s system @myfile.sql
echo systempw | imp system file=myfile.dmp tables=mytable
echo systempw | exp system file=myfile.dmp tables=mytable

Oracle has also provided another method which pads the command line to sqlplus (or any other executable) with just enough blanks to fool the unix ps command into not displaying the actual command line.  To do this, get hide.c (and os.h, if your machine doesn't have it), compile it on your system (the exact compile syntax may vary), move the original sqlplus binary to sqlplus.hide (must have a ".hide" extension), and create a link from "hide" to "sqlplus" (which will run the "hide" binary whenever "sqlplus" is entered on the command line; "hide" will then run "sqlplus.hide" with the command line padded with blanks).  A sample session to do this is shown below:

cc hide.c -o hide
cp hide $ORACLE_HOME/bin
cd $ORACLE_HOME/bin
mv sqlplus sqlplus.hide
ln hide sqlplus

After doing this, any time anyone executes sqlplus with command line options, those command line options will not be visible from ps.  Be aware, though, if you apply any patches to your Oracle bin directory, you must first do a "mv sqlplus.hide sqlplus" to put back the original sqlplus binary into the Oracle bin directory.  Then, after applying the patches, you can once again run through those steps above to create a link from the hide binary to sqlplus.  (Note: I haven't tried using hide.c, since I always use the pipe method, but, I've seen this at several places on the web and listservs, so, I'm including it here in case you want to try it out.)

troubleshooting-defunct-zombie-processes-on-linux

Normally a zombie process means that the process has died but remains in the process table because the parent hasn’t called wait() to “reap” the process and retrieve the return code. If you kill the parent, the zombie process becomes parented by init (process 1) and init reaps it. But, the problem we were having was clearly not this. Killing the parent did nothing. And the defunct agent appeared to be holding onto resources. It was not possible to start a new agent since the defunct one continued to hold a socket open, which would never be true with the usual meaning of a defunct process. The only workaround was to reboot the system.

The key to the real answer is that the agent uses multiple threads with the POSIX threads library. Individual threads and processes under Linux are both viewed as tasks to the process management code. Threads are implemented using one task designated as “thread group leader” and a “thread group id” present in each task_struct. By default, the ps utility displays just the thread group leader, hiding the other tasks.

John Zbesko 25 Mar 2008 - 11:18

Often I’ve encountered a situation where Firefox is hanging on a web page that displays flash video. Even though I close Firefox and look for processes using “ps -ef|grep fire”, I see none. Firefox still will hang if I start again and go to the flash web page.

Only re-booting the machine seems to fix the problem. Is this a similar problem? I’ve also encountered similar problems when messing with the SystemSettings app in Kubuntu when trying to configure less-than-100%-compatible wi-fi devices. Hope this helps…

pomac says 26 Mar 2008 - 8:58

A process reading on a nfs drive can be revived, unmount the nfs filesystem with -lf or so, the key here is -f. Eventually you’ll get a io timeout and all programs will continue working.

What are you doing? I mean why are you blocking on IO in kernelspace? Can it be converted to nonblocking IO?

spinfire says; 26 Mar 2008 - 9:24

Yeah, the NFS mount case can now be fixed with -f. But in the meantime reading processes are in “D” and can’t be interrupted. There are other hardware issues which can cause things to be stuck in uninterruptible sleep perpetually.

The kernel space code used wait_for_completion() which causes uninterruptible sleep. I didn’t write that code, and I haven’t had time to look into why it chose this, except to say wait_for_completion is fairly common in driver code (there is now a timeoutable variant, but it is new, and may not always be appropriate in driver code). In this case I was working with beta drivers, beta hardware, so who knows.

[Aug 15, 2008] Tip of the Trade ps Options By Juliet Kemp

Server Oriented System Tuning Info

Okay, so everyone knows about ps. But I'll just highlight one of my favorite options:

 

ps -eo pid,%cpu,vsz,args,wchan

Shows every process, their pid, % of cpu, memory size, name, and what syscall they are currently executing. Nifty.

redhat.com Home P.S.—I want to see my processes

One of the most basic tools we can use is the utility ps. ps provides a snapshot of current processes. This snapshot can range from myself as a single user (such as what active processes I have running) to all the processes on the system. The simple example of course is to run the ps command with no options, which produces output similar to:

  PID TTY          TIME CMD
 2873 pts/1    00:00:00 bash
 3002 pts/1    00:00:00 ps

Example 1. Basic output of ps

We see in Example 1, “Basic output of ps” that we get some minimal information about the processes we are running, including ps itself. ps displays the process ID (PID), the terminal associated with the process (TTY), the cumulated CPU time in [dd-]hh:mm:ss format (TIME), and the executable name (CMD). Spectacular, right? Well, ps does this and a whole lot more. I should mention at this point that the version of ps that I am using for this article is something special compared to the ps of yester-year and of your classic UNIX®. This ps, procps version 3.2.5, accepts several kinds of options: UNIX options, which may be grouped and must be preceded by a dash, BSD options, which may be grouped and must not be used with a dash, and GNU long options, which are preceded by two dashes. For the uninitiated, those who are new to Linux, or refugees from some older BSD or System V variant, this is good news. A system administrator can track down a process via several sets of options.

root      2784  2774  0 22:45 pts/2    00:00:00 su - mfrye
mfrye     2785  2784  0 22:45 pts/2    00:00:00 -bash
root      2895  1870  0 23:04 ?        00:00:00 sshd: mfrye [priv]
mfrye     2897  2895  0 23:04 ?        00:00:00 sshd: mfrye@pts/3
mfrye     2898  2897  0 23:04 pts/3    00:00:00 -bash
mfrye     3274  2785  0 23:34 pts/2    00:00:00 ps -ef
mfrye     3275  2785  0 23:34 pts/2    00:00:00 grep mfrye

Example 2. Output of ps -ef | grep mfrye

root      2784  0.0  0.0  71368  1288 pts/2    S    22:45   0:00 su - mfrye
mfrye     2785  0.0  0.0  55124  1536 pts/2    S    22:45   0:00 -bash
root      2895  0.0  0.1  38228  2660 ?        Ss   23:04   0:00 sshd: mfrye [priv]
mfrye     2897  0.0  0.1  38228  2748 ?        S    23:04   0:00 sshd: mfrye@pts/3
mfrye     2898  0.0  0.0  55124  1528 pts/3    Ss   23:04   0:00 -bash
mfrye     3272  0.0  0.0  52948   872 pts/2    R+   23:34   0:00 ps aux
mfrye     3273  0.0  0.0  51192   636 pts/2    S+   23:34   0:00 grep mfrye

Example 3. Output of ps -aux | grep mfrye

In Example 2, “Output of ps -ef | grep mfrye” and Example 3, “Output of ps -aux | grep mfrye”, we see the output of ps with different arguments. We can use this output to track a particular set of processes (owned by mfrye) via either of two sets of options (UNIX & BSD, respectively). So what's the big deal, you're thinking? OK, so bash is a pretty tame example. In cases where another process, perhaps one that consumes more memory, or some other resource, than you want, ps can be a very quick, easy, and effective way to track that process down. So now we've tracked down a particular process, but we don't know much more than some basic information about the process's CPU usage in terms of accumulated CPU time, which as you may appreciate, is not ideal. Luckily, there's more.

Killing (Numerous) Processes By S. Lee Henry

Undoubtedly, you are familiar with the kill command, which sends a signal (usually a TERM) to a running process. The default signal, if you don't specify one on the command line, will stop most processes from running. The kill command is an easy command that most Unix users learn, as well as kill -9 (also called the "sure kill"), long before they understand the exact nature of the kill command (i.e., sending a signal which a process will read and process) and its difference from simply stopping a process -- one of many options, though the most common.

When you want to kill a process using a script and need to determine the process ID, or when you want to kill a number of processes without having to use both the ps and kill command for each of them, you run into complications. This column presents a code snippet for killing a number of processes "by name". We use the Bourne shell (this will work with other shells in the Bourne shell family as well) and the xargs command to compose a kill command on the fly.

Here's the code:

------------------------------ cut here ------------------------------
#!/bin/sh

procs2kill="proc1 proc2 proc3 proc4 proc5"

for proc in `echo $procs2kill`
do
  ps -ef | grep $proc | grep -v grep | awk '{print $2}' | xargs -i kill
{}
  $proc killed
done
------------------------------ cut here ------------------------------

The procs2kill variable should define the processes to be killed as precisely as possible -- include as much of a substring as possible so that you will select the proper processes and only the proper processes. If you are overly generous in your specification (e.g., you specify a string that is too general and will match more than a single process), then you might kill more processes than you intended. Once established, the procs2kill variable is then used in the "for" loop to kill each process. The grep -v command removes any sign of the grep command in the process table; the awk command reduces the ps output to the process id column; and the xarg command then creates a kill command with each process id.

The Bourne shell "for proc in " command is very similar to the C Shell's foreach command -- foreach PROC (echo $procs2kill). The syntax is very similar and each command assigns each value, in turn, to the proc variable.

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

ps - Linux Command - Unix Command

ps (Unix) - Wikipedia, the free encyclopedia

docs.sun.com man pages section 1 User Commands ps man page

Suse performance tuning

Reference