How to kill Linux/Unix Processes
Some CSIL Linux users experience either slowness from their system or applications that simply stop responding to user inputs.
Slow (long response time) of a system might indicates ORPHANED or RUNAWAY process(es).
FROZEN or HUNG processes can occur for numerous reasons.
Simply restart the computer most likely correct such difficult situation.
But when the computer has multiple users' active sessions running, restart shall not be the first option. A restart shall not be the first option when the computer has multiple users' active sessions running:
- restart the system has much broader negatively effect on other users on the system.
- the other users' programs my run just fine - thus the restart only creates trouble for them.
- a single program stops responding may not warrant a system restart.
The orphaned processes can occur when software applications are not exited properly, i.e., applications terminate abnormally or unexpectedly.
The orphaned processes may clog up the process table and render the system eventually unusable.
The runaway processes are especially problematic;
- they may appear running normally but stuck in some sort of infinite loop.
- they take up CPU cycles and other computing resources (e.g., memory, storage & network bandwidth) which will result in sluggish performance from the computer.
- in CSIL, we learn how to program; a few programming errors may creep in unexpectedly - yet naturally.
- Every Linux/Unix application is run by the Operating System (O/S) as a separate process.
-
Each process is assigned a unique process ID (pid)
and is stored in the process table while they are loaded.
- a pid will be removed from the process table by the O/S once the application terminates/exits normally.
- - such pid becomes available then it will be re-assigned to a new/different process.
The Orphaned/Runaway processes must be killed off.
A user may only kill off a process if the user is the owner of that process, so it's important to clean up before logoff.
Be aware: logoff may not necessarily terminate orphaned/runaway processes.
- They may continue executing, taking up system resources and slowing done the computer for other users.
- The same principle applies to the CSIL workstations and CSIL CPU Servers and personal Linux computer.
- So, please terminate all known orphaned/runaway processes on CSIL computers and local machine.
If you notice slow performance on a CSIL CPU Server and you see orphaned/runaway processes that don't belong to you, please email helpdesk with as many details as you could. TIA!
To get all the pieces of information we need, we run the ps command like this:
ps -o user,pid,ppid,%cpu,%mem,vsz,rss,tty,stat,bsdstart,cputime,args
Now, list the current user's processes. Here is a sample output:
username@thisPC:~$ ps -o user,pid,ppid,%cpu,%mem,vsz,rss,tty,stat,bsdstart,cputime,args USER PID PPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND username 2713 2657 0.0 0.2 253432 6629 pts/0 R+ 09:02 01:28:00 ssh username@srv1.cmpt.sfu.ca username 4303 4038 0.0 0.0 19444 6872 pts/1 Ss 09:02 00:00:00 -bash username 4879 4454 52.9 0.4 37829 15376 pts/2 Z 09:12 01:35:51 /usr/share/typora/Typora username 5128 4303 23.7 3.1 632170 24728 pts/2 S 09:27 00:22:36 /usr/share/typora/Typora --type=broker username 5211 4303 0.0 0.0 91412 5636 pts/0 R+ 10:14 00:00:00 fbconsole username 7291 4303 0.0 0.0 25791 5636 pts/0 R+ 16:31 00:00:00 ps -u username@thisPC:~$
| col# | Column | Explanation |
|---|---|---|
| 1 | USER | the account running the process, the process owner |
| 2 | PID | the Process ID (pid) - to be used in the kill command |
| 3 | %CPU | CPU time divided by elapsed time (~ load in percentage) |
| 4 | %MEM | resident set size as a percent of physical memory |
| 5 | VSZ | virtual memory size (KB) |
| 6 | RSS | resident set size (KB) |
| 7 | TTY | controlling terminal (? if none) |
| 8 | STAT | process state code (details in next list) |
| 9 | START | start time of this command |
| 10 | TIME | the cumulative CPU time |
| 11 | COMMAND | the command (the program name) with arguments |
The Process state codes (STAT / S):
| Code | Meaning |
|---|---|
| D | Uninterruptible sleep (often disk or NFS); can look "stuck" |
| I | Idle kernel thread (common on newer kernels in some views) |
| R | Running or runnable (on a run queue) |
| S | Interruptible sleep (waiting on I/O or an event) |
| T | Stopped by job control signal (SIGSTOP, SIGTSTP, or debugger) |
| t | Stopped by debugger during trace |
| Z | Zombie (exited but not yet reaped by its parent) |
Step 2 - determine Orphaned/Runaway processes
An orphaned process is one shown by ps that you know you are not using any more,
- you might have aborted it - probably with a key combo Ctrl-C
- or its parent die unexpectedly - i.e., a console window was closed while an application was running in it
The sample output of the ps command above shows the followings:
1. the process with PID 4879 is an orphaned process, since
- it has used a lot of CPU time (95+ minutes).
- it is hours old.
- furthermore, it does not appear to have a parent process (PPID) currently running that is owned by the username.
2. the process with PID 5128 might be a runaway process
- it is hours old.
- it is consuming significant CPU time and possibly other resources.
3. the process with PID 5211 might be an orphaned process
- it does have a valid PPID
- it is also hours old
- and may not be currently running in a window that you could interact with.
- it is probably not a runaway, as it does not take up large amounts of CPU time.
Step 3 - Kill Orphaned/Runaway processes
Use the kill command to terminate the processes (remove processes from the process table).
Once you know which one(s) you want to get rid of, note the Process ID (PID, not the PPID)
of that process as the pid# then execute:
kill pid#
Let's re-use the example, terminate 2 processes like:
kill 4879
kill 5128
To verify these processes are indeed terminated, run our " ps " command gain. - The specific processes should be gone now.
That's all there is to it?
Perhaps, but unfortunately, not all applications trap signals coming from the kill command...
What really happens when you invoke the kill command against a process?
- it makes a system call - instructs the O/S to terminate the specific process.
- the O/S sends the "kill" signal to the specific process.
- the process *may* receive/trap and act upon the kill signal.
- and the "kill" command has the option to send different signals on how the process should be terminated.
Applications must be specifically programmed to accept signals from the O/S.
- when a kill signal is received, the applications may act upon it - we call this graceful termination.
- if an application does not deal with the kill signal properly, it has to be abruptly terminated.
Naturally (yet unfortunately), some applications do listen for kill signals, some don't.
We list 3 ways to kill a process here; first, we should try:
kill -3 pid#
The -3 tells the application running with PID to "quit".
If the application won't listen, try:
kill -1 pid#
The -1 tells the application to "hangup".
If the application still won't listen, try:
kill -9 pid#
The -9 tells the O/S to terminate the application running with PID regardless.
- this -9 method is a drastic way to kill, which should be avoided whenever possible.
- - the process will not be given time to "clean up".
- - the process will not exit gracefully in this case.
Having comments, suggestions, inquiries and more questions? Contact us!
Please click here and use the best practices to get assistance from helpdesk.