我们有一个内部的守护进程，运行在几个RHEL 5盒子上，周期性地发生段错误。 我们的开发人员需要一个核心文件来帮助进行debugging，但是我无法挑起它来制作一个。
$ sudo grep segfault /var/log/messages.1 Aug 11 21:04:13 pal108 kernel: brokend[28692]: segfault at 00000000000000a8 rip 00000031d020f908 rsp 00007fff9c60f3f0 error 4 守护进程使用/etc/init.d/functions的守护进程启动，因此添加
DAEMON_COREFILE_LIMIT=unlimited
到其sysconfig文件应相应地设置ulimit 。 根据procfs说法，这似乎是这样的：
$ sudo grep core /proc/$(cat /var/run/brokend.pid)/limits Max core file size unlimited unlimited bytes
核心文件模式指向一个存在的位置：
$ cat /proc/sys/kernel/core_pattern "/tmp/core_%p_%e_%t"
但它仍然不会产生核心文件。 任何想法可能会阻止这个？ segfault是否意味着操作系统会尝试生成一个核心文件，或者是否依赖于特定于应用程序的编码？
守护进程setuid？ setuid进程默认情况下不会转储核心文件。
运行sysctl fs.suid_dumpable=1启用setuid转储。
是的，当信号发送到产生核心信号的过程时，信号总是被写入：
ABRT 6 core FPE 8 core ILL 4 core QUIT 3 core SEGV 11 core TRAP 5 core SYS core might not be implemented EMT core might not be implemented BUS core core dump might fail XCPU core core dump might fail XFSZ core core dump might fail
应该设置ulimit（正如你已经提到的）。 因为我不知道红帽这么多，我会检查，如果你正在运行deamon的用户ulimit已设置为。 我只是把一个
echo -n "ulimit: " ulimit -c echo -n "For id: " id -u echo
在脚本中testing它。
检查“man core”有一个示例代码来testingcoredumpfunction。 至less在debian下是有的。