For a good introduction to processes, have a look at the slides on our UnixTutorials page. 

  

 !! Useful Process Related utilities 

  

  

 ---- 

  

 !! top 

 * The top line has the uptime, the number of users logged in (according to utmp(5)) and the LoadAverage (according to uptime(1)) 

 * The next line has the number of processes, then a break down of sleeping processes (processes blocked waiting for an event), the number of running processes, the number of [ZombieProcess]es (processes that haven't been cleaned up by their parent process) and the number of stopped processes (processes that are stopped by SIGSTOP) 

 * The next line has the CPU states, amount used in userspace, the amount of CPU used in the system (kernel and device drivers), the amount of cpu used by nice processes (processes that have a lower than normal priority) and the amount of cpu time that is idle (is spent with the cpu shutdown). In more recent versions (such as "procps version 3.2.0"), this line gives a summary of all cpus, for __us__er, __sy__stem, __ni__ce, __id__le, __wa__iting on I/O, __h__ard __I__RQ, and __s__oft __I__RQ. (For this version of top, pressing "1" toggles between 1 summary for all cpus, and a summary line for each cpu.) 

 * Then the memory breakdowns: 

 * The swap breakdown: 

  

 After this comes the list of processes. 

  

 Some hints: 

 * If the number of zombies is high then you possibly have a poorly written program that doesn't cleanup zombies. use pstree(1) to get an idea which process is not cleaning up it's children. 

 * See LoadAverage about the Load average and related issues. 

  

 The various states of a process can be: 

 |^ __State__ |^ __Meaning__ 

 | S | Sleeping 

 | W | Swapped out 

 | R | Running 

 | D | Blocked in a device driver in the kernel. Unkillable. 

 | < | Process is running with a high priority (nice level <0) 

  

 ---- 

  

 !! nice 

  

 nice(1) lets you make programs "nicer" (ie: have less access to the [CPU] in proportion to other processes). nice values in Linux range between -20 and +19. The default nice(1) level is "0". Only the root user can lower their niceless level. Higher nice level means it has a lower priority. A process running at -20 is considered "RealTime" and is never preempted. 

  

  nice -n ''nicelevelchange'' ''program' 

  

 eg: 

  

  nice -n 1 ./program OR nice -1 ./program 

  

 will run ./program with one level higher niceness (ie: *lower* priority compared to other processes). 

  

  nice --5 ./program 

  

 will run a process with lower niceness (ie *higher* priority) of negative 5. (Only the root user can do this). 

  

 ---- 

 !! ps 

  

 If you want to grep for a running process (eg foo) use: 

  

  

 not: 

  

  ps ax | grep foo 

  

 The reason for this is that the latter example will also find the __grep foo__ itself in the process list, while the first one won't. 

  

 The most useful ps(1) command is probably 

  

  ps auxww 

  

 This gives a lot more information about each process than you get by default. 

  

 Here is a poor man's Linux-only ps replacement (for when ps(1) just don't work 

 or can't be relied upon): 

  

  #!/bin/bash 

  echo -ne "$p\0" 

  tr '\0' ' ' < $p/cmdline 

  echo -ne '\0' 

  done | xargs -r0t printf ' %5g %s\n' | sort -ns 

  

 ---- 

  

 !! Miscellaneous 

  

 If you want to unmount a filesystem but it's in use you can use 

  

  ps -auxwwe |grep ''mountpoint'' 

  lsof | grep ''mountpoint'' 

  fuser -vm ''mountpoint'' 

  

 lsof(8) stands for __l__i__s__t of __o__pen __f__iles. 

  

 PerryLorier suggests 

  

  fuser -k -v -m /mnt/nfs 

  

 to kill all processes using that mount point. 

  

 If your program says "[Signal] 11", "SegmentationFault", or similar, you can 

 retrieve information about the process when it crashed. First remove the limit 

 on dumping core files (so it will dump core this time around): 

  

  ulimit -c unlimited 

  

 Then run the program again. (See builtins(1) and ulimit(3) for more information 

 about this.) This time when it [SegmentationFault]s it will leave a file called 

 "core" which contains the state of the program when it died. This file can be 

 inspected by 

  

  gdb ''programname'' ''corefilename'' 

  

 To find out where it crashed try __bt full__ at the prompt. You can also print 

 variables to find out what they currently hold, for example __print argc__ will 

 tell you the contents of argc. Of course, __quit__ or [[Ctrl][[d] will exit 

 gdb. For more information about the [GNU] debugger see gdb(1). For more 

 information about this procedure see DeBugging. 

  

 !!Help I'm running out of file handles, what's using them all? 

  lsof | awk '{print $2}' | uniq -c | sort -n +1 | join -12 -21 - <(ps ax -o pid,command | sort -n) | sort -n +1 

 This one liner lists processes in the form "pid,number of open files,command" with the process using the most files at the end. 

 You can use this to determine which process on your system is leaking file handles, then use strace(1) to figure out why. 

  

  

 !! Saving processes to disc (software suspend) 

  

 Hate having processes die because of kernel upgrades? The thought of losing your irssi scrollback just too much for you?