ps command

In modern Unixes ps is implemented using /proc pseudo filesystem. That means it reads data from it and does not requires additional privileges. See also top command which is a simple monitoring tool for running process similar to ps but able to work in interactive mode.

In most Posix compatible 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

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

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

Actually in Linux with its uncontrollable proliferation of utilities there is a special utility that provides this function:

 pgrep -l

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

How to  find zombie processes?

If you have zombie processes it means a process that has completed execution but still has an entry in the process table.  (look at PPID displayed by ps -l).  See (Zombie process - Wikipedia )

When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, at which stage the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent receives whenever a child has died.

There easiest way to detect zombies is to use command top. It list number of zombies process in the header.

When a process become zombie it consumes almost no resources, so generally they are not dangerous. To find out list of PIDs you can run something like:

# ps aux | awk '{ print $8 " " $2 }' | grep -w Z

Output:

Z 4104
Z 5320
Z 2945

Please note that kill -9 does not guarantee to kill a zombie process.

NEWS CONTENTS

• 20170316 : Important 10 Linux ps command Practical Examples ( Important 10 Linux ps command Practical Examples, Mar 16, 2017 )
• 20170316 : process - Can ps display only non kernel processes on Linux ( Unix & Linux Stack Exchange )
• 20100627 : WebSphere AIX Command Tips ( WebSphere AIX Command Tips, Jun 27, 2010 )
• 20100627 : Show the entire line with the linux-unix ps command ( Show the entire line with the linux-unix ps command, )
• 20100627 : Unix Review Shell Corner PS-n-Grep - The Steroid Version by Ed Schaefer ( Unix Review Shell Corner PS-n-Grep - The Steroid Version, )
• 20100627 : Unix Simplicity Filtering the unix ps command ( Unix Simplicity Filtering the unix ps command, )
• 20100627 : Hiding Passwords From UNIX ps Command ( Hiding Passwords From UNIX ps Command, )
• 20100627 : troubleshooting-defunct-zombie-processes-on-linux ( troubleshooting-defunct-zombie-processes-on-linux, )
• 20080815 : Tip of the Trade ps Options by Juliet Kemp ( August 11, 2008 , serverwatch.com )
• 20080815 : Server Oriented System Tuning Info ( Server Oriented System Tuning Info, )
• 20080815 : redhat.com Home P.S.-I want to see my processes ( redhat.com Home P.S.-I want to see my processes, )
• 20080815 : Killing (Numerous) Processes by S. Lee Henry ( )

Old News ;-)

[Mar 16, 2017] Important 10 Linux ps command Practical Examples

6. Filter processes by thread of process

If we need to know the thread of a particular process, we can use -L option followed by its Process ID (PID). Here's an example of -L option in action :

$ ps -L 1213
.
show processes in threaded view

As we can see, the PID remain the same value, but the LWP which shows numbers of thread show different values.

7. Show processes in hierarchy

Sometime we want to see the processes in hierarchical form. To do this, we can use -axjf options.

$ps -axjf
.
show in hierarchy

Or, another command which we can use is pstree.

$ pstree
.
show information in hierarchy

... ... ...

10. Use PS in a realtime process viewer

ps will display a report of what happens in your system. The result will be a static report. Let say, we want to filter processes by CPU and Memory usage as on the point 4 above. And we want the report is updated every 1 second. We can do it by combining ps command with watch command on Linux.

Here's the command :

$ watch -n 1 'ps -aux --sort -pmem, -pcpu'

[Mar 16, 2017] process - Can ps display only non kernel processes on Linux

Unix & Linux Stack Exchange

Totor asked Jun 7 '13 at 14:06

How can I ask ps to display only user processes and not kernel threads?

See this question to see what I mean...

Hauke Laging

this should do (under Linux):

ps --ppid 2 -p 2 --deselect

kthreadd (PID 2) has PPID 0 (on Linux 2.6+) but ps does not allow to filter for PPID 0; thus this work-around.

l0b0

Nice, but how guaranteed is it that kthreadd is always PID 2?

Stéphane Chazelas

In Linux 2.4 on x86 arch at least, those processes had ppid 1 so couldn't be distinguished that way.

xxx

One way to recognize kernel processes is that they don't use any user memory, so the vsz field is 0. This also catches zombies (thanks to Stephane Chazelas for this observation), which can be eliminated based on their status.

ps axl | awk '$7 != 0 && $10 !~ "Z"'

To list just the PIDs:

ps -e -o pid= -o state= -o vsize= | awk '$2 != "Z" && $3 != 0 {print $1}'

Stéphane Chazelas

Like my solution, it will also include zombie processes.

Stéphane Chazelas

One of the particularity of those processes is that they are not backed by an executable file, so you could do (in zsh):

ps /proc/[0-9]*/exe(^-@:h:t)

Or with any POSIX shell:

ps -p "$(find -L /proc/[0-9]*/exe ! -type l | cut -d / -f3 | paste -sd , -)"

That is check for processes whose /proc/<pid>/exe is a link to a file.

But that means you need to be superuser to be able to check the state of the /proc/<pid>/exe symlink.

Edit: As it happens the zombie processes (at least) satisfy the same condition, so if you don't want them excluded, you'd have to add them back. Like:

ps -p "$(
  { find -L /proc/[0-9]*/exe ! -type l | cut -d / -f3
    ps -eo pid=,state= | sed -n 's/ Z//p'
  } | paste -sd , -)"

Note that ps -f shows those process names in square brackets not because they're kernel processes, but because they have an empty argv[] (so ps shows the process name instead of argv[0] there). You can have a user space process with an empty argv[] as well and you can have a process name with an argv[0] that's of the form [some-string] so filtering the ps output based on those square brackets is not a foolproof option.

Keith Thompson Jun 7 '13 at 20:31

A slightly less unreliable way to get the list of users you're interested in: awk -F: '$7 ~ home { print $1 }' /etc/passwd -- but you'll still get processes that mention any such user name, and you'll leave the temp file lying around. I'll withdraw my downvote, but only because your third solution is reasonable.

terdon

Bah, you're right all the way, @KeithThompson, removed the others, they're not worth it. Could you help me clean up the (now) obsolete comments?

Stéphane Chazelas

Note that $NF is the last word of the command line in ps aux output. Non-kernel processes can have [...] there. As I said in my answer the [xxx] notation is not because they are kernel processes, but because they have no command line (no argument) which is also allowed of non-kernel processes.

@Totor, as I said, the first one is zsh syntax. The second is standard POSIX sh (and ps and find and cut and paste) syntax. Of course /proc is not specified by POSIX. – Stéphane Chazelas Jun 7 '13 at 14:42

Accepting this answer because it's universal (thanks for the edit). However, Hauke Laging's answer is also pretty nice and straightforward as long as you don't deal with a 2.4 kernel. – Totor Jun 8 '13 at 19:12

@Totor, Hauke's answer also has the advantage of not requiring superuser priviledge. My answer works with 2.4 and 2.6/3 kernels, but I suppose there's not guarantee it will work in 4.x anyway. – Stéphane Chazelas Jun 8 '13 at 20:01

Hmm, you're right, I didn't think about root privileges. It can lead to mistakes since you still get an answer when you're not root, but it's different (so you must be cautious when counting them with, say wc -l). Well, I will accept Hauke Laging's answer then, and give you an upvote. ;) – Totor Jun 9 '13 at 22:41

active oldest votes

xxx

In practice I found the following idiom enough:

ps auxf | grep -v ']$'

It filters lines ending with brackets, which might result omitting unwanted entries but it's very unlikely. In exchange it's quite easy to remember and relatively quick to type.

Some processes like avahi-daemon add to their process name information in brackets (the hostname in the case of avahi-daemon) and will be filtered out by this command.

Brackets appear around command names when the arguments to that command cannot be located.

The ps(1) man page on FreeBSD explains why this typically happens to system processes and kernel threads:

If the arguments cannot be located (usually because it has not been set, as is the case of system processes and/or kernel threads) the command name is printed within square brackets.

The ps(1) man page on Linux states similarly:

Sometimes the process args will be unavailable; when this happens, ps will instead print the executable name in brackets.

[Jun 27, 2010] WebSphere AIX Command Tips

Displaying top CPU_consuming processes:

#ps aux | head -1; ps aux | sort -rn +2 | head -10

Displaying top 10 memory-consuming processes:

#ps aux | head -1; ps aux | sort -rn +3 | head

Displaying process in order of being penalized:

#ps -eakl | head -1; ps -eakl | sort -rn +5

Displaying process in order of priority:

#ps -eakl | sort -n +6 | head

Displaying process in order of nice value

#ps -eakl | sort -n +7

Displaying the process in order of time

#ps vx | head -1;ps vx | grep -v PID | sort -rn +3 | head -10

Displaying the process in order of real memory use

#ps vx | head -1; ps vx | grep -v PID | sort -rn +6 | head -10

Displaying the process in order of I/O

#ps vx | head -1; ps vx | grep -v PID | sort -rn +4 | head -10

Displaying WLM classes

#ps -a -o pid, user, class, pcpu, pmem, args

Determining process ID of wait processes:

#ps vg | head -1; ps vg | grep -w wait

Wait process bound to CPU

#ps -mo THREAD -p

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

Softpanorama Recommended

Top articles

Sites

• 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
• Zombie process - Wikipedia, the free encyclopedia

Reference

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019