core dump 为什么通常要关
进程异常终止时内核可以把它的内存镜像写成 core 文件。这些文件里可能带出数据库口令、会话令牌、业务明文数据，安全基线（等保类）一般要求关闭。要注意 systemd 的 coredump.conf、shell 的 ulimit、内核参数三处相互独立，只关一处往往并没有真正关掉。
基本信息
| 配置位置 | /etc/systemd/coredump.conf、limits.conf、/etc/sysctl.d/*.conf |
|---|---|
| 内核侧 | /proc/sys/kernel/core_pattern 决定写入位置与命名 |
| 验证命令 | ulimit -c、coredumpctl list、ls /var/lib/systemd/coredump |
| 生效方式 | systemctl daemon-reload、sysctl -p；服务自身 LimitCORE 单独看 |
| 权限要求 | root |
典型使用场景
- 安全基线核查要求关闭核心转储并留存配置证据
- 排查「磁盘被 core 文件写满」或 /var/lib/systemd/coredump 持续增长
- 确认某个服务是否仍会落盘 core，单元自带 LimitCORE 会覆盖全局设置
- 排障期临时开启 core 定位问题后按流程恢复关闭
- 清查历史遗留 core 文件并纳入定期检查项
检查与关闭
检查与关闭
ulimit -c # 当前会话限制，0 表示不落 core
cat /proc/sys/kernel/core_pattern # 内核侧写入位置与命名规则
cat /etc/systemd/coredump.conf # Storage=none 表示 systemd 不落盘
systemctl show -p LimitCORE app-web # 服务自身的 LimitCORE，可能覆盖全局
coredumpctl list # 已捕获的转储清单
ls -lh /var/lib/systemd/coredump/ # 已落盘的 core 文件
echo 'fs.suid_dumpable=0' >> /etc/sysctl.d/99-security.conf
sysctl -p /etc/sysctl.d/99-security.conf # 立即生效并回显确认三处开关对照
| 位置 | 配置项 | 影响范围 |
|---|---|---|
| systemd | coredump.conf 的 Storage=none、ProcessSizeMax=0 | 由 systemd 托管的服务 |
| shell 限制 | ulimit -c 0 与 limits.conf | 交互会话及继承该限制的进程 |
| 内核参数 | core_pattern、fs.suid_dumpable | 全局行为与 setuid 程序 |
排障期可以临时放开 core 便于分析，但定位完必须恢复关闭状态，并以加固基线文档记录的最终值作为检查依据，避免临时改动留在生产机上。
历史遗留的 core 文件要清理并纳入检查：长期留在磁盘上等于把当时的进程内存（可能含密钥与业务数据）明文存放。
容器场景要单独核查：容器内进程受宿主内核 core_pattern 与容器运行时限制共同约束，只调宿主 shell 的 ulimit 管不到容器内进程，需要同时在宿主与运行时两侧确认。