Linux内核转储需多层权限协同：进程级ulimit、内核core_pattern路径与权限、suid_dumpable参数、systemd服务LimitCORE设置缺一不可，任一环节失败均导致core无法生成。
Linux 内核转储不是“开个开关”就能用，而是多层权限叠加控制的结果：进程级限制、内核路径策略、特权程序拦截、服务管理隔离，缺一不可。
ulimit -c unlimited 为什么只在当前终端生效
这是最常被误以为“设了就全局生效”的陷阱。ulimit -c 是 per-process 的软限制，只影响当前 shell 及其直接 fork 的子进程。它不继承给 systemd 服务、cron job、screen/tmux 会话，更不会跨登录会话生效。
- 临时验证：在目标终端运行
ulimit -c unlimited，再启动测试程序（如含kill -SEGV $$的脚本），观察是否生成 core - 用户级持久化：写入
~/.bashrc或~/.profile，然后source ~/.bashrc；但注意 SSH 登录时若未加载该文件（如使用 non-login shell），仍不生效 - 系统级持久化：编辑
/etc/security/limits.conf，添加两行：* soft core unlimited和* hard core unlimited；必须重新登录才生效，且仅对 PAM 登录会话有效
/proc/sys/kernel/core_pattern 路径和权限必须同时满足
内核只认你写的路径是否存在、父目录权限是否为 1777，其他一概不管。默认值 core 意味着写进当前工作目录——而多数服务的工作目录是 / 或 /var/run，根本不可写。
- 临时设置：运行
echo '/var/crash/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern - 目录必须手动创建：
sudo mkdir -p /var/crash，然后sudo chmod 1777 /var/crash（777不够，1777才是 sticky bit + full rwx） - 永久生效：写入
/etc/sysctl.conf，如kernel.core_pattern=/var/crash/core.%e.%p.%t，再执行sudo sysctl -p - 若值以
|开头（如|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e %p），说明走用户态处理器，需确认systemd-coredump服务已启用并运行正常
setuid 程序崩溃无声无息？检查 kernel.suid_dumpable
sudo、passwd 这类 setuid 程序默认禁止生成 core，不是配置错了，是内核主动拦截。关键参数是 kernel.suid_dumpable，默认为 0（禁用）。
- 临时开启：
echo 2 | sudo tee /proc/sys/kernel/suid_dumpable（2表示在进程dumpable标志为 1 时允许 dump） - 永久生效：写入
/etc/sysctl.conf，如fs.suid_dumpable=2，再sudo sysctl -p - 注意：
kernel.core_uses_pid控制是否在文件名中加 PID，设为1可避免多进程崩溃时覆盖，但非必需项
systemd 服务完全无视 ulimit 和 limits.conf
哪怕你把 /etc/security/limits.conf 配得再完美，systemd 管理的服务照样不生成 core——因为它压根不读这个文件。所有资源限制都由 unit 文件的 Limit* 指令控制。
- 编辑对应 service 文件，如
/etc/systemd/system/myapp.service - 在
[Service]段落中添加：LimitCORE=infinity（或LimitCORE=0表示禁用，infinity才是不限制） - 重载配置：
sudo systemctl daemon-reload，再重启服务：sudo systemctl restart myapp - 验证：运行
systemctl show myapp | grep LimitCORE，输出应为LimitCORE=infinity
真正难调的不是单点配置，而是多层限制的交叠：比如 systemd 服务里开了 LimitCORE=infinity，但进程启动前又被 SELinux 策略拒绝写入目录；或者 core_pattern 指向 NFS 路径，而挂载选项没加 noac 导致缓存不一致。每层都要单独验证，不能靠“应该可以”来推断。
