为何kill命令无法生成core文件而gcore可以？

1. 进程资源限制继承问题 #

你在当前shell执行ulimit -c unlimited，但如果应用是通过sudo、新shell会话（比如桌面快捷方式、systemd服务）启动的，进程会继承父进程的资源限制，而非当前shell的设置。

• 解决：在启动应用的同一shell里先设置限制再启动：

  ulimit -c unlimited && ./my_app
  

• 验证：检查进程实际的core文件大小限制：

  cat /proc/$(pidof my_app)/limits | grep core
  

  确认Max core file size显示为unlimited。

2. apport服务拦截core dump #

Ubuntu默认的apport服务会接管core dump处理，将文件存放到/var/crash/而非你指定的/tmp目录，甚至可能直接抑制生成。

• 临时关闭测试：

  sudo systemctl stop apport
  sudo systemctl disable apport
  

  之后重新发送信号，查看/tmp是否生成core文件。

3. 进程Dumpable属性限制 #

进程可能被设置了PR_SET_DUMPABLE=0，导致内核拒绝生成core文件。

• 检查属性：

  cat /proc/$(pidof my_app)/status | grep Dumpable
  

  如果输出为Dumpable: 0，说明进程不可dump。这种情况可能是应用代码调用了prctl(PR_SET_DUMPABLE, 0)，或是sudo启动后降权触发的安全限制。可以尝试用普通用户直接启动应用，或修改应用代码移除该设置。

4. 自定义信号处理拦截 #

如果应用自行注册了SIGABRT、SIGQUIT等信号的处理函数，且在函数内直接调用exit()而非让进程自然崩溃，内核不会生成core文件。

• 验证：用gdb附加进程后发送信号：

  gdb -p $(pidof my_app)
  (gdb) signal SIGABRT
  

  若gdb能触发core生成，说明应用的信号处理逻辑拦截了默认行为。

内容的提问来源于stack exchange，提问作者my_question