Linux系统死机是运维工作中常见但又令人头疼的问题,与Windows等系统不同，Linux死机时往往无法直接通过图形界面获取错误信息，此时系统日志便成为排查故障的核心依据，本文将从日志位置、关键日志类型、分析方法及实用工具四个方面，详细解读如何通过日志定位Linux死机原因。
核心日志存储位置
Linux系统的日志分散在多个目录中,与系统死机相关的日志主要存放在以下位置：
/var/log/：系统主日志目录，包含大部分关键日志文件。messages：记录系统启动、内核模块加载、服务状态等通用信息。syslog：部分系统仍使用此文件存储系统日志。kern.log：专门记录内核相关的消息（需配置rsyslog）。daemon.log：记录系统守护进程的运行状态。
/proc/：虚拟文件系统，存储内核运行时数据。sysrq-trigger：通过写入命令触发系统状态（需开启Magic SysRq）。last_kmsg（部分发行版）：记录内核崩溃前的最后日志（如CentOS/RHEL）。dmesg：内核环缓冲区日志，记录硬件驱动、内核错误等信息。
关键日志类型分析
内核日志（dmesg）
dmesg是排查硬件相关死机的首要文件，重点关注以下内容：
- 硬件错误：如
DMA parity error（内存错误）、SCSI device did not respond（硬盘故障）。 - 驱动问题：
[<...>] segmentation fault at ...（驱动崩溃）、unable to handle kernel paging request（内存访问违规）。 - 资源耗尽：
Out of memory: Kill process ...（OOM killer触发）、CPU: 0 PID: ... Soft Lockup（CPU软死锁）。
系统服务日志（/var/log/messages）
- 服务崩溃：
[FAILED] Failed to start XXX.service（关键服务启动失败）。 - 资源争用：
file-max limit reached（文件句柄耗尽）、Too many open files。 - 异常中断：
Connection timed out（网络服务超时）、Segmentation fault（应用程序崩溃）。
应用程序日志
位于/var/log/下的子目录（如nginx/、mysql/），记录应用运行时的错误信息，
- 数据库死锁：
Deadlock found when trying to get lock。 - Web服务崩溃：
[emerg] (99: Cannot assign requested address)。
日志分析方法与工具
基础命令分析
- 查看实时日志：
tail -f /var/log/messages | grep -i error。 - 过滤关键词：
grep -i "kernel panic\|segfault\|oom" /var/log/messages。 - 时间范围检索：
sed -n 'May 20 10:00:00,May 20 11:00:00p' /var/log/messages。
专业日志工具
| 工具名 | 功能描述 |
|---|---|
journalctl |
systemd日志管理工具，支持按时间、服务、优先级过滤，如journalctl -xb -p err。 |
logwatch |
自动生成日志摘要，快速定位高频错误。 |
multitail |
同时监控多个日志文件，支持高亮显示关键词。 |
内核调试参数
通过修改/etc/sysctl.conf启用内核日志记录：
kernel.panic = 10 # 死机后10秒自动重启 kernel.panic_on_oops = 1 # 内核错误触发panic
实战案例：定位内存泄漏死机
某服务器频繁出现不定时死机,通过以下步骤排查：
- 提取
dmesg日志：发现大量Out of memory: Kill process，疑似OOM。 - 分析
/var/log/messages：定位到死机前1小时，java进程内存占用持续增长。 - 使用
journalctl -u java -f：捕获到OutOfMemoryError: Java heap space。 - 应用存在内存泄漏,通过重启服务并优化JVM参数解决。
Linux死机日志排查需要结合内核日志、系统服务日志和应用日志，通过关键词过滤和时间线分析逐步缩小范围，对于频繁死机问题，建议开启sysrq和kdump功能，捕获崩溃时的内存快照（/var/crash/），以便更深入分析，日常运维中，定期清理日志（logrotate）和监控日志大小，可避免日志文件过大影响排查效率。
