ulimit -c unlimited只在当前终端生效，因为它是per-process软限制，仅作用于当前shell及其直接fork的子进程，不继承至systemd服务、cron任务、SSH非登录会话，也不跨会话保留。
ulimit -c unlimited 为什么只在当前终端生效
因为 ulimit -c 是 per-process 软限制，只影响当前 shell 及其直接 fork 出的子进程。它不继承到 systemd 服务、cron 任务、SSH 非登录会话（如 ssh host command），也不会跨会话保留。
常见误操作：
- 在桌面终端执行了
ulimit -c unlimited，然后双击启动 GUI 程序 —— 它根本不会读这个设置 - 脚本放进
/etc/cron.d/，崩溃没 core —— cron daemon 自己的ulimit是独立的 -
systemctl start myapp.service启动，结果没 core —— 必须在 unit 文件里加LimitCORE=infinity
验证是否真生效：在目标环境下（比如你准备跑程序的那个终端或服务上下文）直接运行 ulimit -c，输出必须是 unlimited 或一个正整数。
/proc/sys/kernel/core_pattern 路径写入失败的三个硬性条件
内核写 core 文件前做三道检查，缺一不可：
- 目标路径的**父目录必须已存在**，且权限为
1777（sticky bit + rwx for all）。例如设成/var/crash/core.%e.%p.%t，就得提前sudo mkdir -p /var/crash && sudo chmod 1777 /var/crash；755或775都不行 - 如果
core_pattern以|开头（如|/usr/lib/systemd/systemd-coredump %P %u），说明走用户态处理器，此时必须确保对应二进制可执行、有权限，且服务已启用：systemctl is-active systemd-coredump应返回active -
fs.suid_dumpable默认是0，导致sudo、passwd这类 setuid 程序即使ulimit允许也拒绝 dump —— 必须显式设为2：echo 2 | sudo tee /proc/sys/fs/suid_dumpable
systemd 服务怎么开 core dump
systemd 的资源限制完全隔离于用户 shell，改 ulimit 或 /etc/security/limits.conf 对它无效。
正确做法是编辑服务的覆盖配置：
- 运行
sudo systemctl edit myapp.service - 填入：
[Service] LimitCORE=infinity
- 如果程序用了大页内存或
memlock，可能还需加MemoryLimit=infinity和LockPages=false - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart myapp.service
注意：有些发行版（如 RHEL 8+）默认禁用 LimitCORE，即使写了 infinity 也要确认 systemctl show myapp.service | grep LimitCORE 输出是否匹配。
core 文件生成了但内容为空或截断？
这不是配置漏了，而是管道或内存标记导致的静默丢数据：
- 当
core_pattern指向管道（如|/usr/lib/systemd/systemd-coredump）时，/proc/sys/kernel/core_pipe_limit控制缓冲区大小，默认是0（不限），但如果被设成小值（如1），多进程并发 crash 时后到的会被丢弃 - 某些程序（尤其是启用了
memlock或使用大页内存的）可能因 VMA 标记（如VM_DONTDUMP）跳过部分内存段 —— 这不是配置问题，是程序自己要求的 - 用
readelf -l core | grep LOAD看实际加载的 segment 数量，再对比原 binary 的readelf -l /path/to/binary，能快速判断是否缺段
最容易被忽略的是：setuid 程序必须配 fs.suid_dumpable=2，而且这个值不持久，/etc/sysctl.conf 里写了还得 sysctl -p 才真正生效。
