以下是Linux 物理机/云服务器系统卡死的标准化排查流程（兼顾命令行/桌面环境、Docker/服务部署场景），按「紧急恢复→日志溯源→资源排查→深度定位→预防优化」五步执行，直接复制命令即可操作，覆盖 90% 常见卡死场景：
一、紧急恢复：先解决「连不上」的问题（5分钟内）
系统卡死时优先恢复可操作性，再排查根因：
- 物理机/云服务器区分处理：
- 物理机：直接按电源键强制重启（无其他办法）；
- 云服务器：通过控制台「强制重启」→ 用网页/VNC终端登录（避免 SSH 依赖）。
- 单用户模式应急（可选，针对重启后仍卡）：
重启时按Shift进入 GRUB 菜单→选中系统→按e编辑→在linux行末尾加init=/bin/bash→Ctrl+X启动：mount-o remount,rw /# 挂载根目录为可写# 临时禁用可能冲突的服务（如显卡驱动、Docker）echo"modprobe.blacklist=amdgpu">/etc/modprobe.d/emergency.conf systemctl disable --now docker# 若怀疑容器占用资源exec/sbin/init# 恢复正常启动
二、日志溯源：定位卡死前的异常（核心步骤，10分钟）
系统重启后，优先通过日志找「卡死瞬间的关键报错」，重点看上一次启动周期的日志：
1. 系统内核/全局日志（最核心）
# 查看上一次启动的完整日志（卡死前的所有记录）sudojournalctl -b -1 --no-pager|teelast_boot.log# 过滤关键错误关键词（快速定位）sudojournalctl -b -1|grep-E"oom|kill|panic|error|warn|I/O error|soft lockup"--color=auto2. 关键服务日志（按场景筛选）
- SSH 无响应：
sudojournalctl -u sshd -b -1# SSH 服务日志sudogrepsshd /var/log/auth.log.1# 登录日志备份 - 桌面环境卡死：
sudojournalctl -u gdm -b -1# GNOME 显示管理器日志sudocat/var/log/Xorg.0.log.old# X 服务器日志 - Docker/容器相关：
sudojournalctl -u docker -b -1# Docker 服务日志docker logs --tail100可疑容器ID# 容器异常日志
3. 日志关键词对应根因表
| 关键词 | 大概率根因 | 应急处理 |
|---|---|---|
Out of memory: Killed | 内存耗尽（OOM） | 限制进程内存/增加Swap/优化程序 |
kernel panic | 内核崩溃（驱动/硬件冲突） | 回滚内核/禁用冲突驱动 |
CPU soft lockup | CPU 死锁（内核/进程异常） | 杀死占用CPU的进程/更新内核 |
I/O error | 磁盘故障/挂载异常 | 检查磁盘健康/重新挂载分区 |
drm重复初始化 | 显卡驱动异常（如 amdgpu） | 调整驱动参数（如 runpm=0） |
max sessions reached | SSH 连接数耗尽 | 增加 SSH 最大连接数限制 |
三、资源排查：确认是否「资源耗尽」导致卡死（5分钟）
系统卡死最常见原因是 CPU/内存/磁盘耗尽，重启后通过工具回溯历史状态：
1. 内存/CPU 历史占用（需sysstat工具）
# 安装 sysstat（若未安装）sudoaptinstallsysstat -y# 查看上一次启动的 CPU 占用（%idle 接近0=CPU耗尽）sudosar -u -f /var/log/sysstat/sa$(date+%d -d"yesterday")# 查看上一次启动的内存占用（%memused 接近100%=内存耗尽）sudosar -r -f /var/log/sysstat/sa$(date+%d -d"yesterday")2. 磁盘空间与健康状态
# 查看磁盘占用（/ 分区满=卡死常见原因）df-h# 查找大文件（日志/缓存暴增）sudofind/ -type f -size +1G -mtime -1# 1天内新增的1G+文件# 检查磁盘健康（物理机）sudoaptinstallsmartmontools -ysudosmartctl -a /dev/sda# 替换 /dev/sda 为系统磁盘3. 进程异常排查（重启后仍高负载）
# 实时查看高负载进程top# 按 P 排序CPU，按 M 排序内存# 查看历史占用最高的进程psaux --sort=-%cpu|head-10# CPU 最高psaux --sort=-%mem|head-10# 内存最高四、深度定位：针对高频场景的专项排查（10分钟）
若基础排查无结果，按场景专项定位：
1. 显卡驱动异常（桌面环境/物理机）
# 查看显卡驱动状态sudolshw -C display# 确认驱动是否加载dmesg|grep-i"drm"# 驱动初始化日志# 若驱动重复初始化，添加优化参数（如 amdgpu）sudovi/etc/default/grub# 追加 amdgpu.runpm=0 等参数sudoupdate-grub&&sudoreboot2. Docker/容器资源泄漏
# 查看容器资源限制与占用docker stats --no-stream# 实时资源占用docker inspect 容器ID|grep-i"memory"# 查看内存限制# 排查容器日志暴增docker systemdf# 查看容器/镜像占用sudodu-sh /var/lib/docker/containers/*# 容器日志大小3. 内核/硬件兼容性问题
# 查看内核版本uname-r# 查看内核错误日志dmesg|grep-i"bug\|warn\|error"# 检查硬件温度（物理机）sudoaptinstalllm-sensors -ysudosensors# CPU/显卡温度过高=卡死风险4. 服务死锁/端口占用
# 查看服务状态sudosystemctl list-units --type=service --state=failed# 失败服务# 查看端口占用（避免端口冲突导致服务异常）sudonetstat-tulpn|grep-E":22|:80|:3306"# 常用端口五、预防优化：避免再次卡死（长期保障）
排查完后，执行以下优化避免复发：
- 资源限制：
- Docker 容器添加内存/CPU限制：
docker run --memory=4G --cpus=2 ...； - 给进程设置 OOM 优先级：
echo "-1000" > /proc/进程ID/oom_score_adj（避免核心服务被杀死）。
- Docker 容器添加内存/CPU限制：
- 日志管理：
- 配置
logrotate自动轮转日志（避免日志占满磁盘）； - 限制 Docker 容器日志大小：
docker run --log-opt max-size=100m --log-opt max-file=3 ...。
- 配置
- 监控告警：
- 安装
zabbix/prometheus监控 CPU/内存/磁盘； - 简单脚本告警（示例：内存占用超 90% 发邮件）。
- 安装
- 内核与驱动：
- 物理机使用 LTS 内核（如 Ubuntu 22.04 的 5.15 内核）；
- 显卡驱动优先使用官方稳定版，避免盲目更新。
总结：排查流程速记（按优先级）
- 紧急重启→网页/VNC登录；
- 查上一次启动日志（
journalctl -b -1）； - 用
sar看资源占用历史； - 按场景专项排查（驱动/Docker/磁盘）；
- 优化配置避免复发。
按此流程，可在 30 分钟内定位 90% 以上的系统卡死问题，且所有操作均为命令行执行，无需复杂工具，适合技术人员快速落地。
)
