ulimit限制导致的 +++ killed by SIGKILL +++

最新推荐文章于 2023-10-26 14:30:37 发布

转载最新推荐文章于 2023-10-26 14:30:37 发布 · 562 阅读

本文详细解析了一起系统监听异常终止的案例，包括资源限制设置、脚本测试、strace跟踪及sigkill信号分析。通过检查bash历史记录、使用strace和stap工具，最终揭示了监听被终止的原因在于CPU资源使用超出限制，触发了SIGKILL信号。案例还涉及了如何查看进程当前资源限制值，并提供了多种排查技巧。案例中还提及了数据库启动后的特殊限制设置，以及如何通过不同操作系统工具进行深入分析。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

昨天和同事解决了一个案例，主要是同事解决的，我只是提了些建议。

一套系统的监听，不定时的宕掉，是直接就不见了。
最后确定为ulimit中，限制了进程使用的CPU时间数，超过限制值，系统就会粗暴的直接使用kill -9将进程给干掉

模拟下，在/etc/security/limits.conf中设置
oracle soft cpu 1
oracle hard cpu 1

进行ORACLE用户后查看ulimit值,CPU时间已经被限定到60s
[oracle@zhangqiaoc ~]$ ulimit -t
60

编写一个脚本不停的连接数据库
while ((1<2))
do
sqlplus -s ctais2/oracle@o11203 @exit.sql
done

同时使用strace跟踪监听
strace -fo /tmp/strace.out -p 19882

发现监听接收到SIGKILL信号被杀掉。多次测试均一致
19884 +++ killed by SIGKILL +++
19883 +++ killed by SIGKILL +++
19882 +++ killed by SIGKILL +++

然后模拟对监听执行kill -9 ，查看strace的输出，一致
5085 +++ killed by SIGKILL +++
5086 +++ killed by SIGKILL +++
5084 +++ killed by SIGKILL +++

只说明，监听是被kill掉的，那么是何进程kill的监听？
通过 .bash_history 检查，不会发现任何异常命令

strace.out也无法找到更多的信息
但是这个情况，给人的感觉就是监听使用资源到达一定程度，被杀掉了

GOOGLE一下LIMIT的资源限制，可以看到基本都降到ulimit，其中对于CPU限制：
最大允许的CPU使用时间，秒为单位。当进程达到软限制，内核将给其发送SIGXCPU信号，这一信号的默认行为是终止进程的执行。
然而，可以捕捉信号，处理句柄可将控制返回给主程序。如果进程继续耗费CPU时间，核心会以每秒一次的频率给其发送SIGXCPU信号，直到达到硬限制，
那时将给进程发送 SIGKILL信号终止其执行。

在LINUX上，可以使用stap捕获sigkill信号，获得是被何进程kill的
$ cat sigkill.stp
probe signal.send{
if(sig_name == "SIGKILL")
    printf("%s was sent to %s (pid:%d) by %s uid :%d\n", sig_name, pid_name , sig_pid, execname(), uid())
}

$ sudo stap sigkill.stp
SIGKILL was sent to a.out (pid:23700) by a.out uid :50920

在Solaris上，理论上可以使用dtrace来捕获sigkill信号

从linux的源代码中可以看到，超过硬CPU限制就是简单粗暴的让进程被自杀了
参考 http://blog.csdn.net/bingqingsuimeng/article/details/8599668

但是这个案例很奇怪，对于lgwr,dbwr这种进程，竟然没有被自杀，看来是有人在数据库启动后，才做了这样的更改

如何查看进程当前限制值,只知道LINUX，其他平台未知
[oracle@zhangqiaoc ~]$ cat /proc/7455/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              60                   60                   seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            10485760             unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             16384                16384                processes
Max open files            65536                65536                files
Max locked memory         5368832000           5368832000           bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       73728                73728                signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0

启示：
对于稀奇古怪的问题，一般需要先做的检查：
1.安装配置，特别的limit，还有hpux下的/etc/privgroup文件
2.使用raccheck,RDA等工具检查系统
3.strace等工具跟踪
4.还要考虑使用ps -elf / ps vg 一直跟踪进程的资源消耗情况

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8242091/viewspace-776610/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8242091/viewspace-776610/