C++,python,热爱算法和机器学习
全部博文(1214)
分类: LINUX
2014-03-20 17:31:15
原创文章,转载请注明: 转载自系统技术非业余研究
本文链接地址: ulimit -t 引起的kill血案
今天在内核群里印风同学问了个问题:
某台机器的ulimit -t 不知道为啥是300, 这是不是意味着程序占用CPU 300秒后会收到SIGKILL ?
我用gdb跑mysqld 跑了一会,收到SIGKILL信号,没有配置cgroup,也没啥后台脚本,看了下,就ulimit -t 比较诡异,其他机器都是unlimited。
简单的man ulimit下手册说:
-t The maximum amount of cpu time in seconds
貌似限制的是CPU最大执行时间,以秒为单位。
为了验证上面的说法,我特地设计了以下的场景:我们首先运行一个死循环程序消耗CPU时间,同时把进程的最大CPU消耗时间设定在180秒,期待在这个时间点进程会被杀掉。
以下是验证过程:
从现象来看,3分钟后我们的busy进程确实被杀了,dmesg也没说什么原因被杀。
不过不怕我早有准备,提早在运行的同时在另外一个终端开了个stap脚本来确定到底谁杀死了我们的进程:
我们可以看的很清楚是./a.out给自己发的kill信号,属于自杀非他杀,行为有点意思吧!
木名同学找了下内核代码确认了以上行为:
./kernel/posix-cpu-timers.c:1139
内核的代码解释的很清楚,超过硬CPU限制就简单粗暴的让进程被自杀了。之前我还说内核不大可能这么狠,没想到。。。
小结:多看代码,少猜测。
祝大家玩得开心!
Post Footer automatically generated by wp-posturl plugin for wordpress.