Kbase P14679: Guidelines on the use of UNIX kill command to stop a process
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
19/03/2009 |
|
Status: Verified
GOAL:
Guidelines on the use of UNIX kill command to stop a process <PID>
GOAL:
Using UNIX kill signals
GOAL:
Meanings of UNIX kill signals
GOAL:
How to use the UNIX kill command appropriately
GOAL:
How to use kill command to release shared memory
GOAL:
How to use the kill command to cancel processes
FACT(s) (Environment):
UNIX
Products / Versions
FIX:
Use the following options when you use the UNIX kill command to cancel a defunct process or to release shared memory. Issue these kills in the following order until you successfully kill the process.
To obtain the process's pid type:
ps -ef | grep [process]
kill -1 <pid>
-> (SIGHUP) terminal hang up signal
kill -2 <pid>
-> (SIGINT) same as doing a Ctrl+C, terminal interrupt;
kill -15 <pid>
-> (SIGTERM) default if unspecified is a software termination likely to release the lock and shared memory being held. If the process is using cpu time, a kill -15 will generate a core file. A debugger will then be used to generate a stacktrace of the process. Progress Solutions 3167 and P6238 describe how to use debuggers that are most commonly found on UNIX systems.
kill -8 <pid>
-> (SIGQUIT) won't free the lock but produces a memory dump named core in the directory in which the session was started.
kill -9 <pid>
-> (SIGKILL) which truly kills the process and requires the release of held semaphores and shared memory segments for both the user sessions and the broker process (refer to Progress Solution P13793 to check on active message queues, memory, and semaphores).
Note that using kill -9 on Unix systems is not a good idea ("throwing the big red switch") since most systems with their buffered filesystems can get into real trouble. However, in some cases it is better to perform a clean reboot of the system than to start randomly killing processes. Since UNIX does not allow *any* program to detect a kill -9, the Progress server processes cannot detect what is happening when processes start to disappear with kill -9. Depending on the which process is killed off and what the process is doing, the database manager may detect that the process was holding locks in shared memory and is likely to bring the database down. Furthermore, if enough processes are killed off the remaining processes can effectively "hang" since they could be waiting for some resource that will never be released by a lost process.
Note that when a proshut is issued, shutdown is not usually instantaneous. With many users, it may take a few minutes, maybe as long as 30 or more if the transactions are long, because any active transactions need to be backed out BEFORE the disconnect of connected processes occurs .
If proshut -F doesn't seem to work and you are not comfortable killing things off and cleaning up shared memory, then reboot the system.
A kill -16 issued on a process will not kill that process, but should produce a core file and a protrace. The protrace can be useful for Progress techsupport in debugging issues.