ulimit -c 是唯一决定core文件是否生成及大小的开关，/proc/sys/kernel/core_pattern仅控制存储路径和命名，systemd-coredump等配置均受其约束；设为0则内核直接跳过生成，无论其他配置如何。
ulimit -c 是唯一真正控制核心转储是否生成、生成多大的开关，其他所有配置（包括 /proc/sys/kernel/core_pattern）都只管“写到哪”和“叫什么”，不决定“写不写”。
为什么改了 core_pattern 还没 core 文件？
因为 ulimit -c 仍是 0 —— 这是最常见的误判点。内核在写 core 前会严格检查该值，为 0 就直接跳过，连路径都不验证。
-
ulimit -c 0：进程级禁用，哪怕core_pattern指向 /tmp 且权限正确，也绝不会生成文件 -
ulimit -c unlimited：允许写入，大小受磁盘空间和内存实际可用量限制，不是无限占用 -
ulimit -c 204800：限制为 100MB（单位是 512 字节块，别手算错） - systemd 服务完全不继承 shell 的
ulimit，必须在 unit 文件里配LimitCORE=infinity
怎么让 ulimit -c 长期生效？
临时设置只对当前终端及其子进程有效，关掉就失效；要覆盖服务、守护进程、SSH 登录等场景，得走 PAM 机制。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 编辑
/etc/security/limits.conf，追加两行：* soft core unlimited* hard core unlimited -
soft是用户能自己调高的上限，hard是 root 设的封顶值；两者必须都设，否则某些 PAM 配置下soft会被忽略 - 改完需重新登录（SSH 重连、GUI 重启会话），systemd 服务则需
sudo systemctl daemon-reload && sudo systemctl restart xxx - 注意：
/etc/security/limits.conf对容器内进程、cron 任务、已驻留守护进程无效，这些得单独处理
core_pattern 路径写对了却写不进目录？
内核要求：若 core_pattern 含目录层级（如 /var/crash/core.%e.%p.%t），父目录必须存在，且权限必须是 1777（sticky bit + rwx），不是 755 或 777。
- 执行
sudo mkdir -p /var/crash && sudo chmod 1777 /var/crash，缺一不可 - 内核绝不会自动创建父目录，也不会报错，而是静默失败
- 若
core_pattern以|开头（如|/usr/lib/systemd/systemd-coredump），得确认systemd-coredump服务已启用且运行中：systemctl is-active systemd-coredump - 永久生效：写入
/etc/sysctl.conf的kernel.core_pattern=行，再运行sudo sysctl -p
特权程序（如 sudo、passwd）崩溃也不生成 core？
这是 kernel.suid_dumpable 在拦截。默认值为 0，禁止 setuid 程序生成 core，防止提权后泄露敏感内存。
- 临时开启：
echo 2 | sudo tee /proc/sys/kernel/suid_dumpable（值 2 表示在进程标记为 dumpable 时允许） - 永久生效：在
/etc/sysctl.conf中加fs.suid_dumpable = 2，再sudo sysctl -p - 注意：生产环境慎开，尤其对高敏服务；更安全的做法是用
ulimit -c 0或LimitCORE=0显式禁用 - 另外，
core_uses_pid决定是否在文件名中加 PID，避免同名覆盖，建议设为 1：echo 1 | sudo tee /proc/sys/kernel/core_uses_pid
ulimit -c 和 core_pattern 是两层独立控制，漏掉任意一层都会导致 core 不出现；而 setuid 程序还额外卡在 suid_dumpable 上——这三道关卡，缺一不可。
