做国产化桌面支持这行久了你会发现一个特别高频的问题系统偶尔弹出一个程序崩溃提示或者某个应用直接闪退而现场的人往往不知道该怎么把现场完整保存下来。尤其在安可环境的麒麟桌面系统银河麒麟V10这类上“程序崩溃数据”经常被误以为就是截个图、拍个报错弹窗。实际上真正能支撑排查的是core dump、系统日志、应用日志和最小化环境信息这四类东西。这篇文章就围绕麒麟桌面系统“程序崩溃数据”的收集、分析与上报把完整方法说透。1. 崩溃数据到底是什么先分清四样东西再动手1.1 崩溃数据不是一句话是四类信息我在现场经常遇到用户说“我记录了报错弹窗”可真正把报错窗口截图发过去厂商也只能回一句“麻烦提供core文件”。这里的核心差异在于报错弹窗只是“事故通报”core dump 才是“黑匣子”。你可以把core dump理解成程序崩溃那一刻的内存快照。进程为什么崩是空指针、数组越界还是栈溢出崩溃时正在执行哪一行代码调用链长什么样这些都记录在core里。没有core排查只能靠猜。完整的一套崩溃数据包括core dump进程崩溃时的内存转储记录崩溃现场完整调用栈、寄存器和内存数据。系统日志dmesg、journalctl、/var/log/messages 里关于段错误、内存访问异常的记录。应用日志应用自己输出的log很多图形程序还会写 ~/.xsession-errors。环境信息操作系统版本、内核版本、应用安装来源、依赖库版本、是否在用Wine等。这四样缺了哪一样排查效率都会大打折扣。厂商拿到完整包可能一两天就能定位只给一句话“程序崩了”来回沟通两三次都不一定能摸到线索。1.2 麒麟桌面系统默认的崩溃处理机制银河麒麟桌面版V10底层源自Debian系内核默认情况下会把崩溃时生成的core文件交给systemd-coredump处理。也就是说你只要打开系统自带的systemd-coredump服务崩溃时core会被托管到/var/lib/systemd/coredump/目录用coredumpctl工具就能查询和导出。不过这里有个容易踩坑的地方不同版本、不同批次的麒麟桌面系统默认配置并不同。有的版本预装了图形化的崩溃报告工具崩溃时弹窗引导用户上报有的版本则静默处理甚至core被完全禁用。所以不要凭印象判断“它会自己存”一定要到机器上亲自查三项基础开关后面第2节会详细说明。2. 把崩溃数据收集能力打开出事之前先做好三件事做运维的人都有个习惯越安静的机器越危险因为你不知道哪天它会出状况。崩溃数据收集也一样平时花十分钟检查开关等崩溃发生时数据才会在场。2.1 检查当前core文件限制三个命令看清全局登录麒麟桌面系统打开终端依次执行ulimit -c输出如果是0说明当前shell会话禁止生成core这就是很多机器“崩了就崩了什么也没留下”的直接原因。再执行cat /proc/sys/kernel/core_pattern这个文件规定core文件生成到哪里、怎么命名。常见的输出有两类core表示生成在当前工作目录名字就叫core。|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h表示内核把core管道转交给systemd-coredump托管。还有一条可以顺便看一眼cat /proc/sys/kernel/core_uses_pid值1表示core文件名会自动附加PID避免多进程崩溃时互相覆盖值0则不带PID。在多实例场景下建议保持为1。2.2 让崩溃数据稳定落盘推荐一种稳妥组合我自己在生产环境里长期用一套比较省心的配置给没有特殊要求的桌面终端可以直接照抄。先将core_pattern改成直接落盘echo /var/crash/core_%e_%p_%t /proc/sys/kernel/core_pattern这里解释一下为什么用/var/crash而不是/tmp或者家目录/tmp空间小而且系统会定期清理你根本没机会去捞。家目录权限不好控制终端用户多了之后core文件散落各处找起来很麻烦。/var/crash只要提前创建好加个粘性位权限谁崩溃都能写进去运维统一收集也方便。命名规则里%e进程名方便一眼看出是哪个程序崩的。%pPID避免同名进程混淆。%t时间戳按时间排序查找现场。然后把这个配置持久化避免重启后丢echo kernel.core_pattern/var/crash/core_%e_%p_%t /etc/sysctl.d/99-crash.conf sysctl -p /etc/sysctl.d/99-crash.conf再放开用户级限制。在/etc/security/limits.conf里加上* soft core unlimited * hard core unlimited如果你是用systemd管理的系统还要顺便确认coredump的存储限制cat /etc/systemd/coredump.conf里面Storageexternal表示存到磁盘Compressyes表示压缩存储尽量保持这两个默认值能省不少磁盘空间。注意如果你打算走 systemd-coredump 这条默认路线就不要手动改 core_pattern 为直接落盘。两种方式只能二选一否则 coredumpctl 会查不到落盘文件反而造成管理混乱。2.3 顺手清理掉可能捣乱的Apport类工具Debian系系统有时会带Apport这类崩溃报告框架。如果开启状态应用崩溃时它会优先接管弹窗让人误以为系统已经收集了数据实际上Apport对非Ubuntu原生包的效果很一般经常只报“程序已崩溃”然后什么都不留。如果你发现机器上存在apport进程或者/var/crash下有.crash后缀文件建议关闭Apport避免和core dump机制抢数据sudo systemctl stop apport sudo systemctl disable apport sudo sed -i s/^enabled.*/enabled0/ /etc/default/apport保持机制单一后面排查才不绕路。3. 崩溃之后怎么把现场捞出来日志、coredumpctl和gdb三板斧数据收集开关打开后接下来就是真刀真枪地干活了。程序崩溃后按照“先看日志再找core最后gdb定位”的顺序操作能覆盖绝大多数场景。3.1 第一刀先看系统日志里的段错误记录假设你接到现场反馈“XX软件经常闪退”不要着急去翻core先看内核日志dmesg -T | grep -i -E segfault|trap|error | tail -30这段命令能快速看到崩溃进程名、触发地址、错误类型。输出通常是这样的[Fri Mar 14 10:22:31 2025] myapp[12345]: segfault at 4a0f80 ip 00007f2a1c8b3e20 sp 00007ffe2f51d5c8 error 4 in libfoo.so[...]这里的信息非常有价值崩溃发生在libfoo.so这个动态库里错误码4表示“用户态读取非法地址”。再配合journalctl确认一下当天的崩溃事件journalctl --since today | grep -i -E segfault|core-dump|crash | tail -30图形应用的崩溃事件通常也会写进用户会话日志务必再看一眼cat ~/.xsession-errors | tail -100很多Qt、GTK应用的运行时错误都记录在这个文件里现场排查时它比core更快给出线索。3.2 第二刀用coredumpctl精准提取core文件如果你的系统core_pattern走的是systemd-coredump管道那么coredumpctl是操作核心。先列出机器上所有崩溃记录coredumpctl list输出表格里包含时间、PID、进程名、信号等信息。找到目标记录后查看详细信息coredumpctl info PID这里会显示崩溃信号如SIGSEGV、进程命令行、存储路径和压缩状态。确认无误后导出原始corecoredumpctl dump -o /tmp/myapp.core PID导出后先检查文件类型file /tmp/myapp.core正常会输出ELF 64-bit LSB core file之类的描述确认不是空文件、不是被截断的文件再进入下一步。3.3 第三刀gdb定位崩溃调用栈拿到core之后用gdb把崩溃现场调度出来。前提是要知道崩溃程序的可执行文件路径命令格式是gdb /path/to/program /tmp/myapp.core进入gdb交互界面后先看崩溃信息(gdb) bt如果程序崩溃发生在某个共享库里bt输出的栈可能只显示到动态库加载点这时候跑(gdb) thread apply all bt把每个线程的调用栈都打印一遍很多崩溃其实是某个后台线程踩了内存只有全线程栈才能看出来。我实际处理过一个案例主程序看起来很正常但thread apply all bt后发现某个工作线程在释放一个已经被主线程free掉的对象典型的double-free崩溃。如果只盯着主线程栈这个问题根本看不出来。没有符号表的时候gdb会显示()之类的地址定位会费劲一些。建议现场在安装应用时保留调试符号包麒麟源里对应的-dbgsym或-dbg包。如果是单位自研软件开发那边编译时加-g -O0参数生成的core才有完整源码行号信息。提示直接在图形桌面终端里gdb分析超大core文件会吃掉大量内存和CPU建议把core拷贝到专用分析机或者夜间低峰期再跑分析任务。3.4 两类高频场景的特殊处理方式场景一Wine下运行Windows程序崩溃安可环境里经常用Wine跑Windows应用这类崩溃最容易让人一脸懵。因为崩溃的是Windows程序Linux层往往只会留下Wine进程的core可拿这个core分析Windows程序栈基本没有意义。正确做法是先用Wine自己的调试通道WINEDEBUGseh,loaddll,relay wine ./app.exe 2wine.log让Wine把异常处理和模块加载过程完整记下来这比什么都好使。同时收下Linux层core厂商可以通过它判断是Wine版本问题、内核兼容问题还是Windows程序自身问题。建议用GX的稳定版本例如wine-for-麒麟这类定制版而不是自己随便编译一个Wine前者已经处理了大量国产化环境下的兼容问题。场景二Qt、Electron类自研应用崩溃自研GUI应用崩溃时除了core还要收集应用日志和~/.xsession-errors。如果崩溃不好复现建议直接在gdb里运行程序等崩溃发生再抓栈gdb --args ./myapp --debug-modegdb内输入run程序崩溃后执行bt看到完整栈。这种方式比事后分析core更直接还能在崩溃时用print查看变量值。4. 把崩溃数据打包交给厂商标准化才是高效率收集到数据不是终点把数据按厂商能接受的方式整理好才算完成闭环。安可环境的现场往往不止一台机器批量收集和规范打包非常关键。4.1 一台台手动太累写个批量收集脚本如果你的终端数量多建议一个脚本把coredump记录和系统日志全部打包。下面这个脚本适用于core_pattern走systemd-coredump的机器#!/bin/bash HOST$(hostname) TIME$(date %Y%m%d_%H%M%S) DIRcrash_data_${HOST}_${TIME} mkdir -p $DIR # 收集所有core dump清单 coredumpctl list $DIR/coredump_list.txt 21 # 导出最近10条core文件 coredumpctl list --no-pager 2/dev/null | tail -n 2 | head -10 | awk {print $5} | while read pid; do if [ -n $pid ]; then coredumpctl dump -o $DIR/core_${pid}.dump $pid 2/dev/null fi done # 收集内核日志和系统日志 dmesg $DIR/dmesg.txt 21 journalctl --since 7 days ago $DIR/journal_7d.txt 21 # 收集环境信息 { uname -a cat /etc/os-release apt list --installed 2/dev/null | grep -E ^[a-zA-Z].*(wine|qt|gtk|libc6|myapp) } $DIR/environment.txt # 打包 tar czf ${DIR}.tar.gz $DIR echo 打包完成${DIR}.tar.gz这个脚本覆盖了厂商排查需要的四类信息core清单、core文件本身、内核日志、系统日志和环境信息。把压缩包传到厂商那边基本不用再来回拉扯“请提供xx日志”。4.2 给厂商提交崩溃数据的规范清单根据我和厂商打交道的经验一份格式规范的崩溃提交包通常包含这几项core dump文件确认能用gdb正常打开不是损坏文件。复现步骤这个非常关键能复现的崩溃等于问题解决了一半。版本信息OS版本、内核版本、应用版本Wine环境建议带上wine --version。相关日志dmesg、journalctl片段、~/.xsession-errors。脱敏处理日志和core中可能包含用户名、IP、业务数据提交前做脱敏避免泄露。文件名建议统一成应用名_时间_机器名.tar.gz厂商收到后一目了然不用浪费时间改文件名。4.3 最常见的问题崩溃数据根本收不到数据收不到是现场最头疼的情况九成原因集中在下面几个点。ulimit -c为0会话级限制没放开你在limits.conf里改完要重新登录才生效。core_pattern被改成空或者|/bin/false相当于把core扔进了黑洞先用第2节的命令检查。systemd-coredump没有运行执行systemctl status systemd-coredump.socket查看没运行就启动并enable。磁盘满了core写不进去检查/var和/var/lib/systemd/coredump所在分区的剩余空间。程序是被SIGKILL杀掉的SIGKILL信号默认不产生core比如系统OOM时直接杀掉进程这类情况core本来就不会生成只能靠日志定位。5. 常见问题速查与实操心得5.1 高频问题速查表现象可能原因排查思路双击程序没反应无崩溃弹窗启动即静默崩溃看~/.xsession-errors和dmesg提示崩溃但/var/crash里没有corecore_pattern没生效或ulimit为0重新按第2节逐项检查有core文件gdb打开报“not a core file”文件被截断或压缩未解压用file命令检查从coredumpctl导出原始格式coredumpctl list为空core_pattern被改成直接落盘检查/proc/sys/kernel/core_patternWine里的Windows程序崩溃找不到Linux coreWine在用户态处理了异常用WINEDEBUG抓Wine日志程序无响应但不是崩溃死锁或卡IOgdb attach后thread apply all bt看线程栈应用被OOM Killer杀掉内存不足查journalctl -k5.2 一些补充经验并非所有崩溃都值得上gdb有一类崩溃是可以通过崩溃信息直接看出来的。比如libGL.so相关崩溃多半是显卡驱动兼容问题libc.so里崩优先怀疑应用自身内存越界。判断优先级建议是先看dmesg再看崩溃地址在哪一个so里最后才决定是否要开gdb。很多情况下日志已经足够把问题定性不需要动core那个大家伙。另外崩溃不一定都来自应用自身。安可环境的终端硬件差异大尤其是显卡、USB网卡这类设备驱动适配不全会间接导致应用崩溃。遇到图形应用崩溃除了core一定要把lspci -k输出一起收集经常能发现驱动问题。5.3 内核层面的崩溃不要指望core dumpcore dump收集的是用户态进程崩溃内核崩溃完全是另一套机制靠的是kdump。换句话说如果整机直接黑屏重启、死机这种场景不会产生应用core优先启用kdump并保证/var/crash有足够的空间保存vmcore文件。很多单位只配了kdump没检查过落盘空间真出问题时长篇日志根本没存下来这个坑要在系统交付时提前排掉。5.4 我个人的实操心得几次现场踩坑下来我总结出一条给自己贴工位上的流程崩溃发生时先掐时间点找日志再找core最后才分析每次提交厂商的包一定包含“环境信息复现步骤core日志”四件套缺一不可。印象最深的一次现场反馈某办公软件每天下午定时崩溃。我打开journalctl看了一眼发现崩溃时间每天固定在14点02分再查crontab发现是系统的定时任务在扫描某目录触发了应用对文件句柄的误用。整个过程没开一次gdb全靠日志定位。这也印证了一句话core是黑匣子但日志是路标先看路标再开黑匣子效率才是最高的。还有一点想提醒你给终端做批量配置时坏了的core直接删掉别舍不得压缩包堆太多反而干扰后续排查。每台机器留最近几次的有效core就足够了真正有价值的现场数据一次完整的往往就够用。
麒麟桌面系统程序崩溃数据收集与分析：core dump、日志与gdb实战
做国产化桌面支持这行久了你会发现一个特别高频的问题系统偶尔弹出一个程序崩溃提示或者某个应用直接闪退而现场的人往往不知道该怎么把现场完整保存下来。尤其在安可环境的麒麟桌面系统银河麒麟V10这类上“程序崩溃数据”经常被误以为就是截个图、拍个报错弹窗。实际上真正能支撑排查的是core dump、系统日志、应用日志和最小化环境信息这四类东西。这篇文章就围绕麒麟桌面系统“程序崩溃数据”的收集、分析与上报把完整方法说透。1. 崩溃数据到底是什么先分清四样东西再动手1.1 崩溃数据不是一句话是四类信息我在现场经常遇到用户说“我记录了报错弹窗”可真正把报错窗口截图发过去厂商也只能回一句“麻烦提供core文件”。这里的核心差异在于报错弹窗只是“事故通报”core dump 才是“黑匣子”。你可以把core dump理解成程序崩溃那一刻的内存快照。进程为什么崩是空指针、数组越界还是栈溢出崩溃时正在执行哪一行代码调用链长什么样这些都记录在core里。没有core排查只能靠猜。完整的一套崩溃数据包括core dump进程崩溃时的内存转储记录崩溃现场完整调用栈、寄存器和内存数据。系统日志dmesg、journalctl、/var/log/messages 里关于段错误、内存访问异常的记录。应用日志应用自己输出的log很多图形程序还会写 ~/.xsession-errors。环境信息操作系统版本、内核版本、应用安装来源、依赖库版本、是否在用Wine等。这四样缺了哪一样排查效率都会大打折扣。厂商拿到完整包可能一两天就能定位只给一句话“程序崩了”来回沟通两三次都不一定能摸到线索。1.2 麒麟桌面系统默认的崩溃处理机制银河麒麟桌面版V10底层源自Debian系内核默认情况下会把崩溃时生成的core文件交给systemd-coredump处理。也就是说你只要打开系统自带的systemd-coredump服务崩溃时core会被托管到/var/lib/systemd/coredump/目录用coredumpctl工具就能查询和导出。不过这里有个容易踩坑的地方不同版本、不同批次的麒麟桌面系统默认配置并不同。有的版本预装了图形化的崩溃报告工具崩溃时弹窗引导用户上报有的版本则静默处理甚至core被完全禁用。所以不要凭印象判断“它会自己存”一定要到机器上亲自查三项基础开关后面第2节会详细说明。2. 把崩溃数据收集能力打开出事之前先做好三件事做运维的人都有个习惯越安静的机器越危险因为你不知道哪天它会出状况。崩溃数据收集也一样平时花十分钟检查开关等崩溃发生时数据才会在场。2.1 检查当前core文件限制三个命令看清全局登录麒麟桌面系统打开终端依次执行ulimit -c输出如果是0说明当前shell会话禁止生成core这就是很多机器“崩了就崩了什么也没留下”的直接原因。再执行cat /proc/sys/kernel/core_pattern这个文件规定core文件生成到哪里、怎么命名。常见的输出有两类core表示生成在当前工作目录名字就叫core。|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h表示内核把core管道转交给systemd-coredump托管。还有一条可以顺便看一眼cat /proc/sys/kernel/core_uses_pid值1表示core文件名会自动附加PID避免多进程崩溃时互相覆盖值0则不带PID。在多实例场景下建议保持为1。2.2 让崩溃数据稳定落盘推荐一种稳妥组合我自己在生产环境里长期用一套比较省心的配置给没有特殊要求的桌面终端可以直接照抄。先将core_pattern改成直接落盘echo /var/crash/core_%e_%p_%t /proc/sys/kernel/core_pattern这里解释一下为什么用/var/crash而不是/tmp或者家目录/tmp空间小而且系统会定期清理你根本没机会去捞。家目录权限不好控制终端用户多了之后core文件散落各处找起来很麻烦。/var/crash只要提前创建好加个粘性位权限谁崩溃都能写进去运维统一收集也方便。命名规则里%e进程名方便一眼看出是哪个程序崩的。%pPID避免同名进程混淆。%t时间戳按时间排序查找现场。然后把这个配置持久化避免重启后丢echo kernel.core_pattern/var/crash/core_%e_%p_%t /etc/sysctl.d/99-crash.conf sysctl -p /etc/sysctl.d/99-crash.conf再放开用户级限制。在/etc/security/limits.conf里加上* soft core unlimited * hard core unlimited如果你是用systemd管理的系统还要顺便确认coredump的存储限制cat /etc/systemd/coredump.conf里面Storageexternal表示存到磁盘Compressyes表示压缩存储尽量保持这两个默认值能省不少磁盘空间。注意如果你打算走 systemd-coredump 这条默认路线就不要手动改 core_pattern 为直接落盘。两种方式只能二选一否则 coredumpctl 会查不到落盘文件反而造成管理混乱。2.3 顺手清理掉可能捣乱的Apport类工具Debian系系统有时会带Apport这类崩溃报告框架。如果开启状态应用崩溃时它会优先接管弹窗让人误以为系统已经收集了数据实际上Apport对非Ubuntu原生包的效果很一般经常只报“程序已崩溃”然后什么都不留。如果你发现机器上存在apport进程或者/var/crash下有.crash后缀文件建议关闭Apport避免和core dump机制抢数据sudo systemctl stop apport sudo systemctl disable apport sudo sed -i s/^enabled.*/enabled0/ /etc/default/apport保持机制单一后面排查才不绕路。3. 崩溃之后怎么把现场捞出来日志、coredumpctl和gdb三板斧数据收集开关打开后接下来就是真刀真枪地干活了。程序崩溃后按照“先看日志再找core最后gdb定位”的顺序操作能覆盖绝大多数场景。3.1 第一刀先看系统日志里的段错误记录假设你接到现场反馈“XX软件经常闪退”不要着急去翻core先看内核日志dmesg -T | grep -i -E segfault|trap|error | tail -30这段命令能快速看到崩溃进程名、触发地址、错误类型。输出通常是这样的[Fri Mar 14 10:22:31 2025] myapp[12345]: segfault at 4a0f80 ip 00007f2a1c8b3e20 sp 00007ffe2f51d5c8 error 4 in libfoo.so[...]这里的信息非常有价值崩溃发生在libfoo.so这个动态库里错误码4表示“用户态读取非法地址”。再配合journalctl确认一下当天的崩溃事件journalctl --since today | grep -i -E segfault|core-dump|crash | tail -30图形应用的崩溃事件通常也会写进用户会话日志务必再看一眼cat ~/.xsession-errors | tail -100很多Qt、GTK应用的运行时错误都记录在这个文件里现场排查时它比core更快给出线索。3.2 第二刀用coredumpctl精准提取core文件如果你的系统core_pattern走的是systemd-coredump管道那么coredumpctl是操作核心。先列出机器上所有崩溃记录coredumpctl list输出表格里包含时间、PID、进程名、信号等信息。找到目标记录后查看详细信息coredumpctl info PID这里会显示崩溃信号如SIGSEGV、进程命令行、存储路径和压缩状态。确认无误后导出原始corecoredumpctl dump -o /tmp/myapp.core PID导出后先检查文件类型file /tmp/myapp.core正常会输出ELF 64-bit LSB core file之类的描述确认不是空文件、不是被截断的文件再进入下一步。3.3 第三刀gdb定位崩溃调用栈拿到core之后用gdb把崩溃现场调度出来。前提是要知道崩溃程序的可执行文件路径命令格式是gdb /path/to/program /tmp/myapp.core进入gdb交互界面后先看崩溃信息(gdb) bt如果程序崩溃发生在某个共享库里bt输出的栈可能只显示到动态库加载点这时候跑(gdb) thread apply all bt把每个线程的调用栈都打印一遍很多崩溃其实是某个后台线程踩了内存只有全线程栈才能看出来。我实际处理过一个案例主程序看起来很正常但thread apply all bt后发现某个工作线程在释放一个已经被主线程free掉的对象典型的double-free崩溃。如果只盯着主线程栈这个问题根本看不出来。没有符号表的时候gdb会显示()之类的地址定位会费劲一些。建议现场在安装应用时保留调试符号包麒麟源里对应的-dbgsym或-dbg包。如果是单位自研软件开发那边编译时加-g -O0参数生成的core才有完整源码行号信息。提示直接在图形桌面终端里gdb分析超大core文件会吃掉大量内存和CPU建议把core拷贝到专用分析机或者夜间低峰期再跑分析任务。3.4 两类高频场景的特殊处理方式场景一Wine下运行Windows程序崩溃安可环境里经常用Wine跑Windows应用这类崩溃最容易让人一脸懵。因为崩溃的是Windows程序Linux层往往只会留下Wine进程的core可拿这个core分析Windows程序栈基本没有意义。正确做法是先用Wine自己的调试通道WINEDEBUGseh,loaddll,relay wine ./app.exe 2wine.log让Wine把异常处理和模块加载过程完整记下来这比什么都好使。同时收下Linux层core厂商可以通过它判断是Wine版本问题、内核兼容问题还是Windows程序自身问题。建议用GX的稳定版本例如wine-for-麒麟这类定制版而不是自己随便编译一个Wine前者已经处理了大量国产化环境下的兼容问题。场景二Qt、Electron类自研应用崩溃自研GUI应用崩溃时除了core还要收集应用日志和~/.xsession-errors。如果崩溃不好复现建议直接在gdb里运行程序等崩溃发生再抓栈gdb --args ./myapp --debug-modegdb内输入run程序崩溃后执行bt看到完整栈。这种方式比事后分析core更直接还能在崩溃时用print查看变量值。4. 把崩溃数据打包交给厂商标准化才是高效率收集到数据不是终点把数据按厂商能接受的方式整理好才算完成闭环。安可环境的现场往往不止一台机器批量收集和规范打包非常关键。4.1 一台台手动太累写个批量收集脚本如果你的终端数量多建议一个脚本把coredump记录和系统日志全部打包。下面这个脚本适用于core_pattern走systemd-coredump的机器#!/bin/bash HOST$(hostname) TIME$(date %Y%m%d_%H%M%S) DIRcrash_data_${HOST}_${TIME} mkdir -p $DIR # 收集所有core dump清单 coredumpctl list $DIR/coredump_list.txt 21 # 导出最近10条core文件 coredumpctl list --no-pager 2/dev/null | tail -n 2 | head -10 | awk {print $5} | while read pid; do if [ -n $pid ]; then coredumpctl dump -o $DIR/core_${pid}.dump $pid 2/dev/null fi done # 收集内核日志和系统日志 dmesg $DIR/dmesg.txt 21 journalctl --since 7 days ago $DIR/journal_7d.txt 21 # 收集环境信息 { uname -a cat /etc/os-release apt list --installed 2/dev/null | grep -E ^[a-zA-Z].*(wine|qt|gtk|libc6|myapp) } $DIR/environment.txt # 打包 tar czf ${DIR}.tar.gz $DIR echo 打包完成${DIR}.tar.gz这个脚本覆盖了厂商排查需要的四类信息core清单、core文件本身、内核日志、系统日志和环境信息。把压缩包传到厂商那边基本不用再来回拉扯“请提供xx日志”。4.2 给厂商提交崩溃数据的规范清单根据我和厂商打交道的经验一份格式规范的崩溃提交包通常包含这几项core dump文件确认能用gdb正常打开不是损坏文件。复现步骤这个非常关键能复现的崩溃等于问题解决了一半。版本信息OS版本、内核版本、应用版本Wine环境建议带上wine --version。相关日志dmesg、journalctl片段、~/.xsession-errors。脱敏处理日志和core中可能包含用户名、IP、业务数据提交前做脱敏避免泄露。文件名建议统一成应用名_时间_机器名.tar.gz厂商收到后一目了然不用浪费时间改文件名。4.3 最常见的问题崩溃数据根本收不到数据收不到是现场最头疼的情况九成原因集中在下面几个点。ulimit -c为0会话级限制没放开你在limits.conf里改完要重新登录才生效。core_pattern被改成空或者|/bin/false相当于把core扔进了黑洞先用第2节的命令检查。systemd-coredump没有运行执行systemctl status systemd-coredump.socket查看没运行就启动并enable。磁盘满了core写不进去检查/var和/var/lib/systemd/coredump所在分区的剩余空间。程序是被SIGKILL杀掉的SIGKILL信号默认不产生core比如系统OOM时直接杀掉进程这类情况core本来就不会生成只能靠日志定位。5. 常见问题速查与实操心得5.1 高频问题速查表现象可能原因排查思路双击程序没反应无崩溃弹窗启动即静默崩溃看~/.xsession-errors和dmesg提示崩溃但/var/crash里没有corecore_pattern没生效或ulimit为0重新按第2节逐项检查有core文件gdb打开报“not a core file”文件被截断或压缩未解压用file命令检查从coredumpctl导出原始格式coredumpctl list为空core_pattern被改成直接落盘检查/proc/sys/kernel/core_patternWine里的Windows程序崩溃找不到Linux coreWine在用户态处理了异常用WINEDEBUG抓Wine日志程序无响应但不是崩溃死锁或卡IOgdb attach后thread apply all bt看线程栈应用被OOM Killer杀掉内存不足查journalctl -k5.2 一些补充经验并非所有崩溃都值得上gdb有一类崩溃是可以通过崩溃信息直接看出来的。比如libGL.so相关崩溃多半是显卡驱动兼容问题libc.so里崩优先怀疑应用自身内存越界。判断优先级建议是先看dmesg再看崩溃地址在哪一个so里最后才决定是否要开gdb。很多情况下日志已经足够把问题定性不需要动core那个大家伙。另外崩溃不一定都来自应用自身。安可环境的终端硬件差异大尤其是显卡、USB网卡这类设备驱动适配不全会间接导致应用崩溃。遇到图形应用崩溃除了core一定要把lspci -k输出一起收集经常能发现驱动问题。5.3 内核层面的崩溃不要指望core dumpcore dump收集的是用户态进程崩溃内核崩溃完全是另一套机制靠的是kdump。换句话说如果整机直接黑屏重启、死机这种场景不会产生应用core优先启用kdump并保证/var/crash有足够的空间保存vmcore文件。很多单位只配了kdump没检查过落盘空间真出问题时长篇日志根本没存下来这个坑要在系统交付时提前排掉。5.4 我个人的实操心得几次现场踩坑下来我总结出一条给自己贴工位上的流程崩溃发生时先掐时间点找日志再找core最后才分析每次提交厂商的包一定包含“环境信息复现步骤core日志”四件套缺一不可。印象最深的一次现场反馈某办公软件每天下午定时崩溃。我打开journalctl看了一眼发现崩溃时间每天固定在14点02分再查crontab发现是系统的定时任务在扫描某目录触发了应用对文件句柄的误用。整个过程没开一次gdb全靠日志定位。这也印证了一句话core是黑匣子但日志是路标先看路标再开黑匣子效率才是最高的。还有一点想提醒你给终端做批量配置时坏了的core直接删掉别舍不得压缩包堆太多反而干扰后续排查。每台机器留最近几次的有效core就足够了真正有价值的现场数据一次完整的往往就够用。
