SIGTERM与SIGKILL
2013-09-28 18:59
162 查看
SIGTERM vs. SIGKILL
Sending signals to processes using kill on a Unix system is not a new topic for most systems administrators, but I’ve been asked many times about the difference between kill and kill -9.
Anytime you use kill on a process, you’re actually sending the process a signal (in almost all situations – I’ll get into that soon). Standard C applications have aheader file that contains the steps that the process should follow if it receives a particular
signal. You can get an entire list of the available signals on your system by checking the man page forkill.
Consider a command like this:
kill 987
This would send a signal calledSIGTERM to the process. Once the process receives the notice, a few different things can happen:
the process may stop immediately
the process may stop after a short delay after cleaning up resources
the process may keep running indefinitely
The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also,
if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.
Most system administrators will usually resort to the more abrupt signal when an application doesn’t respond to a SIGTERM:
kill -9 987
The -9 tells thekill command that you want to send signal #9, which is calledSIGKILL. With a name like that, it’s obvious that this signal carries a little more weight.
Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn’t even made aware of the SIGKILL signal since the signal goes straight tothe kernel init. At that point, init will stop the
process. The process never gets the opportunity to catch the signal and act on it.
However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won’t be able to stop it.Zombie processes and processes caught in anuninterruptible sleep cannot be stopped
by the kernel, either. A reboot is required to clear those processes from the system.
注意点
1、SIGTERM可以被捕获,SIGKILL不能被捕获;
2、reboot系统前一般是先发SIGTERM,等几秒后再发SIGKILL
3、 reboot发送kill信号时,按照pid从小到大。
4、如果父进程接收到了SIGTERM信号,子进程就接收不到SIGTERM信号了。
5、inittab启动的进程,接受不到SIGTERM信号。
Sending signals to processes using kill on a Unix system is not a new topic for most systems administrators, but I’ve been asked many times about the difference between kill and kill -9.
Anytime you use kill on a process, you’re actually sending the process a signal (in almost all situations – I’ll get into that soon). Standard C applications have aheader file that contains the steps that the process should follow if it receives a particular
signal. You can get an entire list of the available signals on your system by checking the man page forkill.
Consider a command like this:
kill 987
This would send a signal calledSIGTERM to the process. Once the process receives the notice, a few different things can happen:
the process may stop immediately
the process may stop after a short delay after cleaning up resources
the process may keep running indefinitely
The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also,
if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.
Most system administrators will usually resort to the more abrupt signal when an application doesn’t respond to a SIGTERM:
kill -9 987
The -9 tells thekill command that you want to send signal #9, which is calledSIGKILL. With a name like that, it’s obvious that this signal carries a little more weight.
Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn’t even made aware of the SIGKILL signal since the signal goes straight tothe kernel init. At that point, init will stop the
process. The process never gets the opportunity to catch the signal and act on it.
However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won’t be able to stop it.Zombie processes and processes caught in anuninterruptible sleep cannot be stopped
by the kernel, either. A reboot is required to clear those processes from the system.
注意点
1、SIGTERM可以被捕获,SIGKILL不能被捕获;
2、reboot系统前一般是先发SIGTERM,等几秒后再发SIGKILL
3、 reboot发送kill信号时,按照pid从小到大。
4、如果父进程接收到了SIGTERM信号,子进程就接收不到SIGTERM信号了。
5、inittab启动的进程,接受不到SIGTERM信号。
相关文章推荐
- UNIX SIGTERM等信号意义
- 内存不足引起的SIGKILL:一个缓冲区不断增长问题的定位与解决(解释SIGKILL原因)
- emerge --sync时出现rsync error:received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(503)
- 程序捕获退出信号(SIGINT,SIGQUIT,SIGTERM)
- 解决:[WARNING] fpm_children_bury(), line 215: child 2736 (pool default) exited on signal 15 SIGTERM after 59.588363 seconds from start
- sigint sigterm 有什么区别啊
- sigint sigterm 的区别
- sigterm sigint sigkill 区别
- sigint\sigterm\sigkill
- SIGTERM SIGINT
- 内存不足引起的SIGKILL:一个缓冲区不断增长问题的定位与解决(解释SIGKILL原因)
- [WARNING] fpm_children_bury(), line 215: child 9341 (pool default) exited on signal 15 SIGTERM after
- SIGTERM和SIGINT的含义
- 0806编写一个程序,为进程打印SIGINT和SIGTERM信号的掩码
- linux信号 SIGINT SIGTERM SIGKILL
- [WARNING] fpm_children_bury(), line 215: child 2736 (pool default) exited on signal 15 SIGTERM after 59.588363 seconds from star
- 在qt程序中捕捉linux信号,sigint sighup sigterm
- 程序崩溃系统重启问题之 received SIGTERM
- UNIX SIGTERM等信号意义