/bin/sh环境下设置ulimit的一个坑

转自我的网易博客：blacktty.blog.163.com

昨晚收到很多进程不存在的告警，今天在拉开发解决时有人跟我抱怨说，进程挂了没有core文件。我们知道linux的coredump开关就ulimit -c这个，检查现网配置后发现都是unlimited。打包系统也默认在进程启动前显示指定了配置：'ulimit -c 4 -S'，但就是没有corefile，而于此同时，昨天还有一份其他进程coredump的日报。于是问题开始变得越发让人不解。

拉上开发一起，让开发写一个简单的测试进程，提供一个触发coredump的接口用来模拟重现进程coredump。在同一个打包系统打包，选了一个据说进程挂掉没有core文件的机器测试。
1. 完全模拟现网环境，用包管理脚本启动进程，调用接口触发coredump，ps发现进程不存在，没有corefile
2. 登录机器，不用包管理脚本，直接命令行启动进程，调用接口触发coredump，ps发现进程不存在，有corefile

说明包管理的确有问题，重复上面步骤，通过cat /proc/pid/limits查看进程的ulimit参数,发现通过包管理启动的进程Max core file size大小为2k。我们前面提到包管理会显示的配置为4k大小，是不是这个影响了corefile的生成呢？

我在命令行先分别设置corefilesize为2k，4k，然后命令行启动进程，在调用coredump接口测试，发现只有当corefilesize为4k时才会生成corefile，继续测试3k也不行。这里基本可以确定：corefilesize的值不小于4才会生成corefile

最后问题落在为什么在包管理系统中分明显示指定了corefilesize的值，进程实际运行后会变成2k？我们模拟包管理启动方式，corefilesize设置4k
1. 把ulimit设置、程序命令行启动方式写在脚本里启动 ， 测试ok
2. 查看包管理脚本发现都是用的/bin/sh,遂把测试脚本都改用/bin/sh, 测试没有生成corefile ! 查看进程的corefilesize值，果然是2k！而且更改设置为8k后可以顺利生成corefile。

原因找到，是/bin/sh环境下ulimit设置有问题，strace跟踪发现 

.... ...
read(255, "#!/bin/sh\nulimit -c 4 -s\n", 25) = 25
...
setrlimit(RLIMIT_CORE, {rlim_cur=2*1024, rlim_max=RLIM_INFINITY})
... ...

设置limit时变成了2*1024, 出现问题的系统版本为： centos 6.3 x86_64 

update:
1. 2013-07  回家后在 2.6.18-308.el5的centos 5.8上测试/bin/sh环境正常， 这个情况可能是部分系统存在。