Linux core dump配置实战：从systemd-coredump到内核参数排查

简介这份PDF是一份面向SAP实施顾问与MM模块运维人员的配置实操详解围绕转储配置中最常用的采购订单与库存运输订单展开。内容从PO编号范围、PO类型设置讲起深入说明通过OMH6、OMEU、OMEC等事务代码完成编号与单据类型定义并针对跳号问题给出了SNRO缓冲区设置方法。文档还覆盖报表查询按类型分类、定价方案按场景区分、错误提示与价格差异限制配置重点演示了SE16:T160M及通过V_160M在PRD直接修改配置的技巧并结合STO的intra-company与cross-company配置实例帮助读者理解从后台表结构到界面消息控制的完整链路。全书以图文截图辅以作者实际排错经验尤其适合需要快速上手SAP转储配置、想避开常见跳号与消息控制坑点的中高级顾问参考。资源为单个PDF文件体积约3.36MB内容精炼但覆盖完整已有171人学习下载是一份可直接对照体统操作的实用手册。1. 转储配置崩溃现场到底有没有留下来全看这一份文档接手一台新机器时我最先翻的往往不是业务配置而是这份「转储配置.pdf」。原因是很多线上故障根本复现不了崩溃后的 core dump 是唯一的物证。可现实里十台机器有七台会在崩溃瞬间白屏等我去/var/crash或者 coredump 目录找现场时只看到一行刺眼的 journal 日志未配置任何 coredump 目标。无法保存主机核心转储。这份文档表面上是转储机制的参数手册实际上决定了一件事进程被信号打死的那一刻内核是把内存镜像写进磁盘还是直接丢进黑洞。它解决的是「崩溃了能不能找到证据」这个最基础的问题适合每个做服务端开发、运维、SRE 的人。这篇文章我按自己配置这套方案的完整路径来讲从转储目标和内核参数对照关系一直讲到真正落盘的文件长什么样。2. 转储配置最少要搞懂的三个对象内核、systemd-coredump 与 ulimit2.1 核心转储由谁触发从缺省行为到 systemd 接管在 Linux 里进程崩溃时内核会检查RLIMIT_CORE这个资源限制然后决定要不要生成 core 文件。传统做法是直接写到工作目录下名字叫core或core.PID。这个行为有两个致命的短板一是进程的工作目录随时可能没有写权限二是多实例部署时 core 文件会被互相覆盖。于是 systemd 接管了这套逻辑——把内核的 core_pattern 指向 systemd-coredump 这个用户态程序由它统一收集、压缩、登记再按配置归档。这个分工是理解整套转储配置的起点也是我在「转储配置.pdf」里最先核对的部分。内核侧的取证点有两个第一个是kernel.core_pattern它决定了内核把崩溃现场交给谁第二个是kernel.core_pipe_limit它限制了并发的转储管道数。实际排查时直接读这两个参数比靠猜靠谱得多。# 查看当前内核把 core 交给谁处理 sysctl kernel.core_pattern # 典型输出|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h # 看到以管道符开头说明内核把现场交给了 systemd-coredump 程序 # 查看管道并发限制0 表示不限制 sysctl kernel.core_pipe_limit每次配置完转储方案我第一步就是执行这两条命令确认内核侧确实指向了 systemd-coredump。sysctl kernel.core_pattern输出里的%P是崩溃进程的 PID%u和%g是用户和组%s是终止信号编号%t是时间戳%c是当时的 core 文件大小限制%h是主机名。这段格式是内核文档里定义的systemd 侧完全依赖它来恢复现场。之前遇到过一次「配置了 coredump 但还是不落盘」的翻车查到最后就是kernel.core_pattern被人改成了空的core绕过了 systemd文件写到了进程工作目录又被系统清理掉现场全无。这就是不核对内核参数的下场。2.2 systemd-coredump 的配置优先级coredump.conf 是入口systemd-coredump 的配置集中在/etc/systemd/coredump.conf或者放在/etc/systemd/coredump.conf.d/目录下的 drop-in 文件里。前者是主配置后者是优先级更高的局部覆盖配置。两者同时存在时后者会覆盖前者的同名项。这个设计是我比较喜欢的因为它允许我保持主配置不动把灰度机器的特殊要求写在 drop-in 里回滚时只删文件即可。配置项里最核心的是Storage它决定转储文件的去向。可选值有三个none表示完全不保存只把崩溃信息记到日志里external表示把 core 文件存到/var/lib/systemd/coredump/journal表示把 core 存进 journal 日志系统。需要注意的是journal模式会让日志体积暴涨生产环境很少用。Compress默认是yes用 zstd 压缩实测一个几百 MB 的 core 能压到十分之一。ProcessSizeMax限制了 systemd-coredump 处理的最大体积超过限额的 core 直接不处理这个参数在内存很大的机器上特别容易踩坑。我最常用的配置是这样# 写入 /etc/systemd/coredump.conf.d/override.conf [Coredump] Storageexternal Compressyes ProcessSizeMax2G ExternalSizeMax2G写完后执行systemctl daemon-reload和systemctl restart systemd-coredump.socket让配置生效。对于进程自身来说shell 的 ulimit 限制必须在启动进程前解除否则即使 systemd 侧配置好了进程因为RLIMIT_CORE为 0 而根本不会触发 core dump。常见做法是修改服务的 systemd unit 文件在[Service]段里加一行LimitCOREinfinity再daemon-reload。这个细节我把它排在最前面是因为「改完 coredump.conf 不生效」的案例里十有八九是卡在这一步。3. 在 systemd 机器上配好落盘转储从检查 socket 到 coredumpctl 验证3.1 启动前检查systemd-coredump.socket 为什么必须处于激活状态systemd-coredump 的运行模型是 socket 激活。也就是说 systemd-coredump 这个服务平时不常驻内存只有内核把崩溃现场通过管道送过来时systemd-coredump.socket 才会把服务拉起来。如果 socket 没有启动内核侧的 core_pattern 即便指向了 systemd-coredump数据也送不进去结果就是崩溃现场丢失journal 里再次出现那句最让人头疼的「未配置任何 coredump 目标。无法保存主机核心转储」。所以配置转储方案的第一步不是改配置文件而是检查 socket 状态# 查看 systemd-coredump.socket 是否处于激活状态 systemctl status systemd-coredump.socket # 如果没激活立即启动并设置开机自启 systemctl enable --now systemd-coredump.socket # 检查 systemd-coredump 服务是否存在且未被 mask systemctl status systemd-coredump.servicesocket和service的关系我说得直白一点socket 是门口的信箱service 是处理信件的文员。信箱没装好信件全丢文员被停用信箱满了也没人取。很多一键巡检脚本只会看 service 状态忽略了 socket这是排查时容易遗漏的盲区。另外需要注意systemctl enable --now是同时完成启动和开机自启两个动作之前有同事用systemctl start启动后没 enable机器一重启又回到原状这种事多发生几次就长记性了。3.2 最小可用配置把 Storage 设为 external 并加上限生产环境的转储配置有一条铁律core 文件必须落盘成独立文件方便后续用 gdb 或 crash 工具离线分析。所以我不推荐Storagejournal虽然在 systemd 新版里 journal 模式也能保存但 journal 会做额外处理而且文件提取时要走 journalctl 一层层的过滤远不如直接去/var/lib/systemd/coredump/目录下拿文件顺手。最小可用配置写出来就四行[Coredump] Storageexternal Compressyes ProcessSizeMax0 ExternalSizeMax0这里我把ProcessSizeMax和ExternalSizeMax设成了0意思是系统默认值。实际上 systemd 的默认值是2G也就是说超过 2G 的 core 文件会被丢弃。如果你跑的是内存占用很大的 Java 服务或数据库崩溃时的 core 可能超过这个值必须显式调大。我一般是这样权衡先看机器物理内存大小再估算崩溃瞬间进程占用的虚拟内存量最终设一个比进程最大虚拟内存大 20% 的值。设得过大也有风险磁盘会被瞬间写满所以压成 zstd 这步一定要保留。Compressyes在生产环境必须开原因很实际磁盘上同时存在多个 core 时压缩能省掉大量空间而且读取时 systemd-coredump 会自动解压不影响后续 gdb 分析。3.3 强制生成一次 core 来验证整条链路kill -SEGV 不是开玩笑配置完成之后最重要的事是验证。我习惯用一个故意崩溃的进程来测试整条链路而最可靠的方式是让某个进程直接段错误退出。这里注意不要拿业务进程做实验我会写一个最小测试程序或直接使用 bash 的kill -SEGV。# 方法一使用 sleep 进程触发 SIGSEGV sleep 60 PID$! kill -SEGV $PID # 此时 sleep 会因为段错误崩溃触发 core dump # 方法二使用 bash 内置命令让当前 shell 崩溃 # 实际上直接对 bash 发 SEGV 可能不触发转储因为 bash 可能自己处理信号 # 等待几秒后用 coredumpctl 查看是否捕获到崩溃 coredumpctl list --no-pager | tail -20方法一更可靠。注意sleep 60 这条命令启动了后台进程拿到 PID 后立刻发SIGSEGV。这里有个细节触发 core dump 的信号可以是SIGSEGV、SIGABRT、SIGBUS等但有些进程会自己捕获信号做清理后再退出那样可能不会产生 core所以用kill -SEGV是最直接的暴力测试方式。如果coredumpctl list里能看到对应的条目说明整条链路已经通了。tail -20是防止条目太多刷屏实际使用时根据机器上的历史崩溃记录调整行数。之后再去/var/lib/systemd/coredump/目录下确认.zst文件已经生成整个落盘验证就算完成了。3.4 用 coredumpctl 提取和分析转储文件gdb 定位到源代码行文件落盘只是转储配置的终点真正能让它发挥作用的是后续分析。coredumpctl这个命令既能列出所有崩溃记录也能直接调用 gdb 进入调试会话。核心用法是把上次崩溃的 core 文件加载进调试器# 查看最近一次崩溃的详细信息 coredumpctl info --no-pager # 直接启动 gdb 分析最近一次崩溃 coredumpctl gdbcoredumpctl info会输出崩溃进程的可执行文件路径、信号的类型、触发崩溃的指令地址还有进程当时的工作目录。这些信息在判断「崩溃发生在初始化阶段还是运行阶段」时非常关键。coredumpctl gdb则是一条省事的命令——它自动找到最近的 core 文件并交给 gdb。在 gdb 里输入bt就能看到完整调用栈如果程序带有调试符号甚至能直接看到崩溃的那一行源代码。我见过不少人绕了一大圈去/var/lib/systemd/coredump/底下找文件路径再用gdb 可执行文件 core文件手动拉起调试。coredumpctl gdb这条命令能省不少事。4. 转储配置避坑别让崩溃现场在最后一米丢失4.1 坑一core_pattern 被改成普通文件路径systemd 完全没参与现象coredump.conf 配置了 Storageexternalcoredumpctl list 里也有历史记录但新崩溃就是不落盘journal 里出现「未配置任何 coredump 目标。无法保存主机核心转储」。原因某次巡检时有人执行了sysctl -w kernel.core_patterncore把内核的 core 输出恢复成了传统方式全部写到崩溃进程的工作目录。systemd-coredump 被完全绕开coredumpctl 自然查不到记录。解决恢复 core_pattern 指向 systemd-coredump。同时检查/etc/sysctl.conf或/etc/sysctl.d/下是否有持久化配置覆盖只改运行时值不写配置文件重启后还会再犯。这个坑我踩过一次之后就长记性了每次改完内核参数必须确认落盘sysctl -w只是临时生效机器重启就还原。4.2 坑二ProcessSizeMax 默认值导致大内存应用崩溃无转储现象服务内存占用超过 2G崩溃后 coredumpctl list 里完全没有记录journal 显示 systemd-coredump 已经处理但没有任何文件落盘。原因systemd-coredump 的ProcessSizeMax默认是 2G崩溃进程的 virtual memory 超过了这个上限systemd 直接丢弃了转储数据。日志里不会明确告诉你「因为超过上限所以丢弃」只有一行状态码很容易被忽略。解决显式把ProcessSizeMax调大同时注意ExternalSizeMax也要跟着调整因为前者管的是进程内存大小后者管的是落盘文件大小。内存 32G 的机器上我会设置成ProcessSizeMax6G配合ExternalSizeMax6G留足余量。但磁盘空间是硬约束如果 /var/lib/systemd/coredump 所在分区只有 10G 容量设置再大的限额也只是加速磁盘写满。4.3 坑三ulimit -c 0 让内核根本不生成 core配置再对也没用现象所有 systemd 层配置都正确手动 kill -SEGV 测试也能捕获但某个服务崩溃时就是没有 core。原因该服务的手动启动脚本里有ulimit -c 0或者 shell 环境默认限制了 core 文件大小。内核收到崩溃信号后会先检查进程的 RLIMIT_CORE值如果为 0 就直接放弃生成 core根本不走 core_pattern 的管道。这个现象用「玄学」来形容一点不过分——看起来所有系统配置都对实际死在进程自己的资源限制上。解决在启动脚本里显式执行ulimit -c unlimited或者在 systemd unit 文件里配置LimitCOREinfinity然后systemctl daemon-reload重启服务。排查时用cat /proc/PID/limits查看进程实际生效的 core file size 限制确认到底是多少。之前遇到过 systemd unit 文件已经写了LimitCOREinfinity但进程没重启旧进程还带着老的限制在跑这也是个容易忽略的点。4.4 坑四coredump.conf 改了不生效drop-in 文件的命名规则错了现象修改了/etc/systemd/coredump.conf.d/custom.conf里的 Storage 配置systemctl daemon-reload也执行了但coredumpctl info显示文件还是存到了 journal 里。原因drop-in 文件的命名必须以后缀.conf结尾放在/etc/systemd/coredump.conf.d/目录下且文件名排序在99开头的会覆盖10开头的。如果文件命名成了custom.conf.bak或者目录不对systemd 会直接忽略它。另外一个常见原因是/etc/systemd/coredump.conf主文件里已经设置了 Storagejournal但 drop-in 文件的字段名写错了比如大小写不对systemd 解析时静默忽略。解决先用systemd-analyze cat-config systemd/coredump.conf查看所有生效配置的完整叠加结果确认 drop-in 文件确实被读取了。再检查文件后缀和目录权限/etc/systemd/coredump.conf.d/目录下的文件属主应该是 root权限不能太宽松。这一点是血泪经验systemd 对配置文件权限有要求chmod 777的文件它大概率直接忽略。4.5 坑五磁盘空间不足导致落盘失败转储数据被静默丢弃现象崩溃后 coredumpctl list 有记录但记录里没有 core 文件journalctl -u systemd-coredump*显示存储失败。原因coredump 目录所在分区满了。systemd-coredump 不会因为磁盘满而阻塞进程崩溃流程它会放弃保存并只在日志里留一行错误。这个行为本身是合理的但问题是日志消息级别不高排查时容易遗漏。解决确保/var/lib/systemd/coredump/所在分区有充足空间监控磁盘使用率并把该目录纳入告警阈值。同时可以配置一个定期清理策略比如用 logrotate 或者 systemd-timer 定期清理超过多少天的转储文件。生产环境我会写一个简单的 find 命令结合 crontab 每周清一次超过 7 天的文件find /var/lib/systemd/coredump/ -name core* -mtime 7 -delete这条命令会把 7 天前的 core 文件全部删除。它没有复杂的逻辑但能防止磁盘被一点一点耗尽。要注意的是这只适用于确定不需要的旧转储如果业务有合规审计需求需要先归档再删除不能直接这样清。5. 转储文件命名与格式从 core.xxx.zst 里读出全部上下文5.1 文件名是元数据的浓缩PID、时间戳和信号都在里面systemd-coredump 落盘的文件名格式是有规律的理解它之后在紧急时刻能省去打开 coredumpctl 的功夫。默认格式通常长这样core.可执行文件名.PID.时间戳.zst。比如一个叫 nginx 的进程崩溃后生成的文件可能是core.nginx.12345.20250121103000.zst。从这个名字里能直接读出三件事崩的是哪个程序、进程号是多少、崩溃发生的精确时间。这个文件名格式不是随便定的。它在coredump.conf里可以通过Filename参数覆盖但不建议动。原因有两个第一默认格式已经包含了定位问题所需的核心元数据第二coredumpctl 在索引转储记录时依赖文件名和 journal 里的元数据对应关系如果自造了文件名格式可能导致 coredumpctl 无法把记录和文件关联起来。另外zst 后缀表明文件是 zstd 压缩过的不要直接用file命令去识别要记得它是压缩格式。查看实际文件时可以用coredumpctl info PID来获取更完整的信息它会把文件路径、大小、崩溃信号都列出来比直接去目录里 ls 更结构化。如果遇到coredumpctl list显示有记录但info查不到文件路径的情况大概率是Storagejournal导致 core 存在 journal 里没落盘。5.2 分析转储的标准姿势先看日期再看进程名最后确认信号拿到一堆 core 文件之后分析顺序也有学问。我见过有人直接下载文件丢进 gdb结果分析的是几天前的旧崩溃浪费时间不说还得出错误结论。正确的做法是# 列出最近 20 条崩溃记录先做时间排序确认目标 coredumpctl list --no-pager | head -20 # 确认目标 PID 后查看详细信息 coredumpctl info PID # 如果文件已经归档到别处用 gdb 手动加载分析 gdb /usr/sbin/nginx /var/lib/systemd/coredump/core.nginx.12345.20250121103000.zsthead -20和前面用tail -20有所不同——list 默认按时间倒序排列最新的在最上面所以用 head 才能看到最近的记录。对于崩溃时间点的确认可以结合业务监控平台的告警时间来交叉核对如果时间对不上说明还有更早的崩溃被漏掉了。gdb命令的最后一个参数是压缩文件也直接支持gdb 能自动调用 zstd 解压不需要手动先解压。不过这里有一个小坑如果 gdb 版本太老可能不支持 zstd 压缩格式遇到这种情况就用zstd -d先解压再加载。查当前位置的 core 文件格式时也不要依赖扩展名用file命令会给出真正的文件类型说明。5.3 转储文件该保留多久存储成本与取证窗口的平衡转储文件保留周期的设计容易走极端。保留太短线上问题还没来得及分析就被清掉了保留太长几十 GB 的 core 文件堆在磁盘上吃空间。我的经验是分两层策略短期保留 7 天给一线排查留窗口长期保留则根据业务重要性筛选只保留核心服务的崩溃转储普通服务不留。一个粗糙但实用的方案是把转储目录做成单独的挂载点比如/var/lib/systemd/coredump单独挂一块盘容量按机器内存的两倍规划。这样即便 core 文件写满这块盘也不会拖垮系统盘。如果机器是容器化部署要注意容器内崩溃时生成的 core 可能落在容器可写层里容器销毁后文件就没了。遇到这种情况我一般会把kernel.core_pattern指向宿主机的一个固定路径或者挂载宿主机的转储目录到容器内。对于 Kubernetes 环境直接把宿主机/var/lib/systemd/coredump挂给 Pod 是一种简单粗暴但确实有效的方案前提是给 Pod 配置好相应的权限。6. 把转储配置固化到文档和初始化流程一份 PDF 应该承载的全部内容6.1 从配置到交付唯一真正该写进转储配置文档的四件事如果你是为了团队交付而写这份转储配置说明或者要把现有配置沉淀成「转储配置.pdf」这样的交付文档那么核心内容应该包含四件事内核参数的预期值、systemd 配置文件的完整内容、验证命令的执行结果样例、以及排障时的排查顺序。这份文档的价值不在说教而在让接手的人可以在十分钟内独立完成验证。我习惯把文档写成可执行的形式而不是大段解释。比如内核参数部分直接写清楚执行命令和期望输出# 期望输出|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h sysctl kernel.core_pattern同时附上一段systemd-analyze cat-config systemd/coredump.conf的期望输出让接手的人一眼看出当前配置的叠加效果。文档里还要写明验证步骤执行一次 kill -SEGV 测试然后查 coredumpctl list 确认新记录出现。这比任何原理讲解都实用。6.2 初始化脚本的通用模板新建机器时自动完成转储配置既然文档是给机器初始化用的那不如直接把初始化脚本也写进这套交付方案里。这样新机器上线时只需要跑一个脚本就能保证转储配置一致不会出现「开发机配了、生产机没配」的割裂局面。下面这个脚本是我在用的模板兼顾了 systemd 配置、内核参数和 ulimit 三个层面#!/bin/bash # 转储配置初始化脚本适用于 systemd 系 Linux 发行版 set -euo pipefail # 1. 确保 systemd-coredump socket 处于激活状态 systemctl enable --now systemd-coredump.socket # 2. 写入转储配置external 存储压缩开启大小限制 4G mkdir -p /etc/systemd/coredump.conf.d cat /etc/systemd/coredump.conf.d/override.conf EOF [Coredump] Storageexternal Compressyes ProcessSizeMax4G ExternalSizeMax4G EOF # 3. 确保内核 core_pattern 指向 systemd-coredump # 如果被改过写回标准配置 if ! sysctl kernel.core_pattern | grep -q systemd-coredump; then sysctl -w kernel.core_pattern|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h echo kernel.core_pattern|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h \ /etc/sysctl.d/60-coredump.conf fi # 4. 重载 systemd 配置并验证 systemctl daemon-reload systemctl restart systemd-coredump.socket echo coredump 配置完成当前 core_pattern sysctl kernel.core_pattern这段脚本里的set -euo pipefail是 bash 的安全模式任何一步出错就立即退出避免带病继续执行。写入 drop-in 文件时用了 heredoc 语法EOF 用单引号包住防止变量展开。第 3 步先检查再写入避免了每次执行都重复覆盖内核参数。最后输出当前 core_pattern 作为人工确认点。这套脚本在 Ubuntu 和 CentOS 系都跑得通唯一可能不同的地方是 systemd-coredump 的安装情况——如果最小化安装没有这个包需要先apt install systemd-coredump或yum install systemd-coredump。6.3 文档之外的习惯崩溃发生后先冻结现场再谈定位配置做好之后真正考验人的是崩溃发生时的处置习惯。我的原则是崩溃发生后第一件事不是去讨论根因而是先把转储文件拷贝到一个安全位置。因为这个文件可能很大分析会持续很长时间而磁盘空间可能同时被其他日志蚕食。# 崩溃发生后立即备份转储文件 mkdir -p /data/crash_backup cp -a /var/lib/systemd/coredump/ /data/crash_backup/ ls -lh /data/crash_backup/cp -a保留了文件属性和时间戳这些信息在后续分析中可能有用。备份完成后再慢慢跑coredumpctl info和 gdb时间上从容很多。这套操作我已经形成肌肉记忆了——每次哪台机器出问题第一反应就是先把现场保住再谈其他。一份配置文档、一个初始化脚本、一个备份习惯这三样组合起来才是完善的转储配置方案。如果这套东西没有沉淀成文档和脚本纯粹靠人肉记着那下次新机器上线又得靠运气。希望帮到你。本文还有配套的精品资源点击获取