The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
signal的sigkill信号，也就是kill -9 pid是无法在程序内部捕获的，那怎么办？你反抗不了，一般关于sigkill的日志会在/var/log/messages里，如果非deamon程序在终端也是有日志体现的。对于内核暴力完杀，你只能找到原因避开程序的sigkill信号。
再次申明下，程序是无法捕获sigkill的信号，在python下注册sigkill捕获事件，直接给你扔出个runtimeError异常.
该文章写的有些乱，欢迎来喷 ! 另外文章后续不断更新中，请到原文地址查看更新。 http://xiaorui.cc/?p=3121
#xiaorui.cc In [3]: def trycache(*args): ...: print args ...: In [4]: signal.signal(signal.SIGKILL,trycache) --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) <ipython-input-4-7f0697d1acc4> in <module>() ----> 1 signal.signal(signal.SIGKILL,trycache) RuntimeError: (22, 'Invalid argument')
一般我们常用的kill信号有这么几种, 而sigterm 也就是直接kill pid是默认信号.
SIGINT 2 用户调试终止进行中断，一般是键盘（Ctrl + C）。 SIGABRT 6 调用abort函数产生（通常是自杀）。 SIGTERM 15 kill命令发送的默认终止信号。
插入一句, signal.signal(signal.SIGCHLD,func_sigchld) 可以捕获子进程exit前发出的sigchld，然后在func_sigchld定义waitpid()来收拾。这样可以避免僵尸进程的存在。 另外要注意信号不排队的问题，你可以循环检查waitpid()子进程的状态.
我们再来说说, 一般什么时候会发生内核sigkill你的应用程序，这里不聊你自己手动去kill -9 pid。
1. 一般是你的程序写的不严谨，内核要给别人分配内存时，一看没有可用的，这时候就可能会把你给宰了，专业说法是内存泄漏引起的OOM killer.
2. 如果你的应用超出你设置的cpu使用时间，那么也会被kill，可以使用ulimit -t查看。
ulimit -t
cpu time (seconds, -t) unlimited
3. 权限安全问题，这个倒是没啥，咱们很容易分析出来.
$ touch /var/xiaorui.cc
touch: /var/xiaorui.cc: Permission denied
SIGTERM vs. SIGKILL 区别?
sigterm 是可以捕获的，你可以针对该信号注册函数.
sigkill 如此文，无法捕获.
这两天又把linux系统编程过了一遍，受益匪浅 ！ 推荐大家闲来无事时看看底层的东西，像我以前遇到僵尸进程，要不就直接全套孤儿进程的方案，要不就修复内部的逻辑. 看了这两天linux编程，才知道解决方案有多种多样.
