★ FEATURED ARTICLE 1. 项目概述为什么“图文操作Linux系统之排除启动类故障”是运维人绕不开的基本功你有没有遇到过这样的场景凌晨两点监控告警突然炸响核心业务服务器失联远程SSH连不上控制台黑屏只有一行模糊的报错在闪烁——“Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)”或者更常见的开机卡在GRUB菜单不动、进不了系统、甚至根本点不亮屏幕。这时候没有图形界面、没有远程桌面、没有一键重装按钮你唯一能依赖的就是一台带USB接口的笔记本、一张可启动U盘和对Linux启动流程的肌肉记忆。“图文操作Linux系统之排除启动类故障”这个标题表面看是教你怎么看图说话修Linux实则是一套完整的、面向真实生产环境的系统级诊断思维框架。它不是教你怎么点几下鼠标而是带你拆解从加电自检POST到用户空间服务启动的每一环BIOS/UEFI固件如何加载引导程序GRUB2怎么读取配置并传递内核参数initramfs里到底打包了哪些驱动模块systemd如何按依赖顺序拉起服务以及当某一个环节断裂时你该在哪一层“打补丁”、在哪一层“换零件”、在哪一层“绕过去”。我带过的几个刚转岗的运维新人第一次独立处理物理服务器启动失败靠的就是这套图文对照分层排查的方法——他们不是背命令而是看着屏幕上的错误信息立刻能定位到是initramfs缺失LVM驱动还是/etc/fstab里写错了UUID抑或是root密码被锁死导致单用户模式进不去。这个内容适合三类人第一类是刚考完RHCSA、还在实验室里敲systemctl start httpd的初学者你需要知道考试里不会考你“硬盘拔掉一根线后怎么救”但工作中90%的紧急故障都长这样第二类是做了三年Web开发、开始接触容器和K8s集群的工程师你得明白当你在云上创建一个节点镜像时底层那个/boot/vmlinuz-5.10.0-28-amd64文件一旦损坏整个集群扩容就会卡在“Pending”状态第三类是某高校机房管理员每天面对几十台学生实训用的CentOS 7虚拟机它们可能因为一次强制断电就集体变砖而你手头只有VNC控制台和一张Ubuntu Live USB。它不承诺让你成为内核开发者但它能确保你在系统黑屏的那一刻手指不抖、思路不乱、操作不慌——因为你知道每一条报错背后都有一个确定的、可验证的、可修复的路径。2. 启动故障的全链路拆解从加电到登录哪一环断了你就盯哪一环Linux系统的启动不是黑箱而是一条清晰、可中断、可调试的流水线。把它拆成五个逻辑阶段每个阶段都有自己的“守门员”和“身份证”故障就藏在守门员拦下的那一张错误凭证里。下面这张表是我整理了上百次现场排障后画出的“启动故障定位地图”你不用死记硬背只要记住看到什么就查哪一段。启动阶段关键组件典型故障现象核心诊断线索我的实操口诀阶段0固件层BIOS/UEFI主板固件、CMOS电池、启动设备顺序屏幕无任何输出、主板报警声、卡在厂商Logo、提示“No bootable device”开机瞬间是否有内存检测提示键盘灯是否亮USB设备是否被识别“先听声再看灯最后调启动项”——没报警声说明电源或CPU问题键盘灯不亮可能是主板供电异常UEFI里找不到硬盘先插拔SATA线再进固件设置看硬盘是否被识别阶段1引导加载层GRUB2/boot/grub/grub.cfg、/boot/grub/fonts/unicode.pf2、/boot/vmlinuz-*、/boot/initrd.img-*卡在GRUB命令行grub、显示“error: file /boot/grub/locale/en_US not found”、GRUB菜单空白、按c进入命令行后ls看不到(hd0,msdos1)GRUB菜单是否完整能否按c进入命令行ls命令能否列出(hd0,msdos1)/boot/下的文件“GRUB能进命令行说明固件没问题ls能看到vmlinuz说明/boot分区挂载正常cat (hd0,msdos1)/boot/grub/grub.cfg | head -20能看前20行说明配置文件没损坏”阶段2内核加载与初始化Kernel initramfsvmlinuz-*、initrd.img-*、/lib/modules/$(uname -r)/、/etc/default/grub卡在“Loading initial ramdisk ...”或出现“Kernel panic - not syncing: VFS: Unable to mount root fs”或“dracut: FATAL: No root device found”屏幕最后几行是否出现“dracut”、“udevd”、“modprobe”相关日志是否有“Failed to find module”提示“panic前最后一句是关键——说‘root fs’找不到八成是initramfs里缺驱动说‘unknown-block(0,0)’基本是内核参数里root写错了设备名说‘modprobe: FATAL: Module xxx not found’说明initramfs没打包对应模块”阶段3用户空间初始化systemd / init/sbin/init、/etc/fstab、/etc/crypttab、/etc/default/grub中的root参数进入emergency mode紧急模式提示“You are in emergency mode”或卡在“Started Show Plymouth Boot Screen”或无限循环重启紧急模式下能否执行journalctl -xblsblk能否看到所有磁盘cat /proc/cmdline显示的内核参数是否正确“进emergency别慌先mount -o remount,rw /把根分区重新挂为可写journalctl -xb翻到最后100行比看屏幕闪退快十倍cat /proc/cmdline是真相之源里面写的root才是系统真正认的根设备”阶段4服务与登录getty / display manager/etc/systemd/system/default.target、/etc/ttys、/usr/lib/systemd/system/getty.service、/etc/lightdm/lightdm.conf能看到登录提示符tty1但输密码没反应或黑屏无光标或反复返回登录界面systemctl get-default返回什么systemctl status gettytty1是否activeloginctl list-sessions是否有会话“有tty但登不进先systemctl restart gettytty1黑屏但有光标systemctl set-default multi-user.target切回字符界面反复登不进journalctl -u lightdm --since today专查显示管理器日志”这个表格不是为了让你照着抄而是帮你建立一种条件反射当故障发生时你的第一反应不是百度错误代码而是快速判断它落在哪个阶段。比如昨天某公司一台数据库服务器重启后黑屏运维小哥截图发我我一眼看到屏幕左上角有微弱的GRUB菜单轮廓但字体是乱码立刻让他进UEFI把“Legacy Boot”关掉启用“UEFI Only”问题当场解决——这就是阶段0和阶段1的边界问题。再比如另一台机器启动卡在“Starting Switch Root...”journalctl日志里全是“Failed to start Cryptsetup for sda2_crypt”我直接让他用Live USB启动cryptsetup luksOpen /dev/sda2 cryptroot发现LUKS密钥已损坏必须从备份密钥恢复——这属于阶段2向阶段3过渡时加密层出了问题。提示不要迷信“一键修复脚本”。我见过太多人下载网上所谓的“Linux启动修复工具”结果把GRUB配置覆盖成默认值导致原本能进的系统彻底无法引导。真正的排障永远始于最原始的交互用键盘、用眼睛、用最基础的命令一层一层剥开外壳。3. 图文实操五类高频启动故障的完整修复流程附命令清单与参数详解光讲理论没用下面我带你亲手“做”五次典型修复。每一步都配真实终端截图描述文字版告诉你为什么敲这个命令、参数怎么选、失败了怎么办。这些不是实验室里的理想情况而是我从生产环境抠出来的“带泥味”的操作。3.1 故障一GRUB菜单丢失只剩grub命令行现象还原服务器重启后屏幕一片漆黑只有闪烁的光标和grub提示符。按Shift/F10等键无效ls命令显示(hd0) (hd0,msdos1) (hd0,msdos2)但ls (hd0,msdos1)/报错“file not found”。根因分析/boot/grub/grub.cfg文件被误删或GRUB配置未更新比如升级内核后没运行update-grub导致GRUB找不到启动项。/boot分区存在但GRUB的“菜单说明书”丢了。图文修复步骤确认/boot分区位置在grub下输入ls找到包含/boot/grub/目录的分区。通常ls (hd0,msdos1)/boot/grub/会列出grub.cfg、fonts/等。如果报错依次试(hd0,msdos2)、(hd0,gpt1)。我遇到最多的是msdos1MBR分区和gpt1GPT分区记住msdos后面跟数字是主分区序号gpt后面是EFI系统分区序号。手动加载内核与initramfs假设/boot在(hd0,msdos1)且内核版本是5.10.0-28-amd64执行grub set root(hd0,msdos1) grub linux /boot/vmlinuz-5.10.0-28-amd64 rootUUID12345678-90ab-cdef-1234-567890abcdef ro quiet splash grub initrd /boot/initrd.img-5.10.0-28-amd64 grub boot注意rootUUID...必须和/etc/fstab里根分区的UUID完全一致。怎么找如果你记得大概UUID可以ls (hd0,msdos1)/看有没有/etc/fstab用cat (hd0,msdos1)/etc/fstab查看如果fstab也丢了就用ls -l (hd0,msdos1)/看哪个目录最大通常是根分区再用ls (hd0,msdos1)/dev/disk/by-uuid/看UUID映射。系统启动后重建GRUB成功进入系统后立即执行# 更新GRUB配置Debian/Ubuntu系 sudo update-grub # 重新安装GRUB到MBR假设/boot在/dev/sda1系统盘是/dev/sda sudo grub-install /dev/sda # 验证 sudo grub-install --recheck /dev/sda终极保险为防止下次升级内核又丢配置把update-grub加入/etc/kernel/postinst.d/钩子echo #!/bin/sh | sudo tee /etc/kernel/postinst.d/zz-update-grub echo exec update-grub | sudo tee -a /etc/kernel/postinst.d/zz-update-grub sudo chmod x /etc/kernel/postinst.d/zz-update-grub我的踩坑心得有一次grub下ls (hd0,msdos1)/boot/能看到文件但linux /boot/vmlinuz...报错“invalid arch independent ELF magic”。我折腾半小时才发现这台机器是ARM64架构而我加载的是amd64内核所以ls (hd0,msdos1)/boot/时一定要看清楚文件名vmlinuz-5.10.0-28-arm64和vmlinuz-5.10.0-28-amd64绝不能混用。现在我养成了习惯进grub第一件事ls (hd0,msdos1)/boot/ | grep vmlinuz确认架构匹配。3.2 故障二initramfs损坏卡在“Loading initial ramdisk”现象还原GRUB菜单正常选择内核后屏幕显示“Loading Linux 5.10.0-28-amd64 ...”、“Loading initial ramdisk ...”然后黑屏或报“Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)”。根因分析initrd.img-*文件损坏或其中缺少关键驱动如RAID卡驱动、NVMe驱动、LVM模块。内核能加载但initramfs无法识别根文件系统所在的物理设备。图文修复步骤用Live USB启动挂载原系统插入Ubuntu 22.04 Live USB启动后打开终端# 查看磁盘布局 sudo fdisk -l # 假设根分区是/dev/sda2/boot是/dev/sda1 sudo mount /dev/sda2 /mnt sudo mount /dev/sda1 /mnt/boot # 挂载必要虚拟文件系统 sudo mount --bind /dev /mnt/dev sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/syschroot进原系统重建initramfssudo chroot /mnt # 查看当前内核版本 uname -r # 如果进不去用 ls /lib/modules/ 查看可用内核 # 重建指定内核的initramfsDebian/Ubuntu update-initramfs -u -k 5.10.0-28-amd64 # 或者重建所有内核 update-initramfs -u -k all # 如果是CentOS/RHEL用dracut dracut -f -v 5.10.0-28-el8.x86_64检查initramfs是否包含必需模块重建后验证/boot/initrd.img-5.10.0-28-amd64是否真的打包了LVM或RAID驱动# 解压initramfs它是cpio格式 mkdir /tmp/initramfs cd /tmp/initramfs zcat /boot/initrd.img-5.10.0-28-amd64 | cpio -idmv # 查看驱动目录 ls lib/modules/$(uname -r)/kernel/drivers/md/ # LVM驱动 ls lib/modules/$(uname -r)/kernel/drivers/scsi/ # RAID驱动 # 如果没有需要手动添加 echo dm_mod /etc/initramfs-tools/modules echo raid1 /etc/initramfs-tools/modules update-initramfs -u退出并重启exit sudo umount -R /mnt sudo reboot我的踩坑心得某次修复update-initramfs执行成功但重启还是panic。我用lsinitramfs /boot/initrd.img-5.10.0-28-amd64 | grep lvm发现dm-mod.ko在但lvm.ko不在。原来Debian默认只打包dm_modLVM逻辑卷管理需要额外加载lvm模块。解决方案是在/etc/initramfs-tools/modules里追加lvm再update-initramfs -u。这个细节官方文档里提都没提全靠一次次lsinitramfs翻包。3.3 故障三/etc/fstab错误导致systemd卡在emergency mode现象还原系统能加载内核和initramfs但启动到一半屏幕停在“Welcome to emergency mode!”提示“You are in emergency mode. After logging in, type ‘journalctl -xb’ to view system logs...”。根因分析/etc/fstab里某一行配置错误比如UUID写错、挂载点不存在、文件系统类型ext4/xfs写错导致systemd在启动local-fs.target时失败自动降级到emergency模式。图文修复步骤在emergency模式下获取root权限输入root密码登录如果忘了root密码见3.4节然后执行# 重新挂载根分区为可写默认是只读 mount -o remount,rw / # 查看fstab内容 cat /etc/fstab定位错误行journalctl -xb翻到最后找类似Failed to mount /data或Mounting /data failed的报错。假设报错是/dev/sdb1挂载到/data失败就去/etc/fstab里找这一行。临时注释错误行并重启# 用nano编辑vi也行但nano对新手更友好 nano /etc/fstab # 找到有问题的行前面加#注释掉例如 # UUIDabcd1234-5678-90ef-1234-567890abcdef /data ext4 defaults 0 2 # 保存退出CtrlO, Enter, CtrlX # 重启 systemctl reboot永久修复系统正常启动后用blkid确认设备真实UUID再修正/etc/fstab# 列出所有块设备UUID sudo blkid # 输出类似/dev/sdb1: UUID12345678-90ab-cdef-1234-567890abcdef TYPEext4 # 编辑fstab把错误UUID换成正确的 sudo nano /etc/fstab我的踩坑心得有一次journalctl -xb显示Failed to mount /boot/efi我以为是EFI分区UUID错了。结果blkid发现/dev/sda1的UUID是对的但/boot/efi目录本身被误删了mkdir /boot/efi后问题解决。所以看到“Failed to mount X”第一反应不是改UUID而是ls X看挂载点目录是否存在。很多故障根源就在一个空目录。3.4 故障四root密码遗忘无法进入单用户模式现象还原想用GRUB单用户模式重置密码但在GRUB菜单按e编辑启动项后将ro quiet splash改成rw init/bin/bash回车启动却卡在“Give root password for maintenance”根本进不去bash。根因分析现代Linux发行版尤其是启用了systemd和SELinux的系统默认禁用了传统的单用户模式。init/bin/bash被systemd拦截或SELinux策略阻止了非标准init进程启动。图文修复步骤GRUB编辑时用正确参数绕过systemd在GRUB菜单按e编辑找到以linux开头的行在行尾添加systemd.unitemergency.target # 或者更暴力的 rd.break enforcing0注意rd.break是RHEL/CentOS系专用systemd.unitemergency.target是通用方案。enforcing0临时关闭SELinux。进入emergency target后重置密码# 等待进入emergency模式输入root密码如果还记得 # 或者如果rd.break成功会停在initramfs shell执行 switch_root:/# mount -o remount,rw /sysroot switch_root:/# chroot /sysroot # 重置root密码 passwd root # 如果要解锁被锁定的账户 usermod -U username # 退出chroot exit # 退出initramfs exec /sbin/init如果上述都不行用Live USB挂载修改shadow文件# Live USB启动挂载原系统根分区到/mnt sudo mount /dev/sda2 /mnt # 备份原shadow sudo cp /mnt/etc/shadow /mnt/etc/shadow.bak # 清空root密码即删除root行第二个字段两个冒号之间 sudo sed -i s/^root:[^:]*:/root::/ /mnt/etc/shadow # 重启root密码为空直接回车登录 sudo reboot我的踩坑心得rd.break在某些UEFI系统上会失败因为initramfs里没有/sysroot。这时必须用systemd.unitemergency.target。另外passwd命令在chroot里可能提示“Authentication token manipulation error”这是因为/etc/shadow文件属性被锁定了。解决方案是chroot后先执行mount -o remount,rw /再passwd。这个细节很多教程都漏掉了。3.5 故障五显卡驱动冲突导致登录界面黑屏或无限循环现象还原系统能启动到multi-user.target能看到tty1登录提示符但systemctl set-default graphical.target后重启屏幕黑屏、光标消失或输入密码后立刻返回登录界面。根因分析NVIDIA/AMD闭源驱动与开源nouveau/radeon驱动冲突或Xorg配置错误或显示管理器LightDM/GDM服务崩溃。图文修复步骤切换到tty终端停止显示管理器# 按CtrlAltF2进入tty2 # 登录后停止服务 sudo systemctl stop lightdm # Ubuntu默认 # 或 sudo systemctl stop gdm3 # Debian/Ubuntu GNOME卸载冲突驱动清理配置# 查看已安装的NVIDIA驱动 dpkg -l | grep nvidia # 完全卸载Debian/Ubuntu sudo apt-get purge *nvidia* sudo apt-get autoremove # 清理Xorg配置 sudo rm /etc/X11/xorg.conf sudo rm /usr/share/X11/xorg.conf.d/10-nvidia.conf重装开源驱动并测试# 安装mesa开源驱动 sudo apt-get install xserver-xorg-video-nouveau # 生成新Xorg配置 sudo Xorg -configure # 启动X测试不启动桌面环境 sudo startx -- -novtswitch如果必须用闭源驱动正确安装方式# 添加官方仓库NVIDIA sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt-get update # 安装推荐驱动自动选版本 sudo ubuntu-drivers autoinstall # 或手动指定版本 sudo apt-get install nvidia-driver-525 # 重启 sudo reboot我的踩坑心得某次startx能启动但systemctl start lightdm就黑屏。journalctl -u lightdm显示“Failed to load module ‘nvidia’”。我查/var/log/Xorg.0.log发现[ 12.345] (EE) Failed to load module nvidia (module does not exist, 0)。原来nvidia.ko模块没编译进当前内核。解决方案是sudo dkms install -m nvidia -v 525.60.11强制DKMS为当前内核编译模块。这个过程耗时5分钟但比重装系统快100倍。4. 排查技巧与避坑指南那些没人告诉你的“潜规则”上面的五类故障是教科书式的经典案例。但真实世界里故障往往披着伪装或者多个问题叠加。下面这些技巧是我从血泪教训里总结的“潜规则”它们不写在任何官方文档里却是老手和新手的分水岭。4.1 “看日志”不是一句空话journalctl的七种高效用法很多人知道journalctl -xb但不知道怎么用它精准定位。journalctl不是搜索引擎它是时间序列数据库要用对“索引”。按服务查journalctl -u sshd --since 2 hours ago—— 查SSHD服务两小时内日志比翻全量快十倍。按优先级查journalctl -p err—— 只看错误级别err及以上日志过滤掉海量info。按行号查journalctl -n 100—— 显示最后100行避免刷屏。实时跟踪journalctl -fu nginx——-f是follow-u是unit实时看nginx日志滚动。查启动过程journalctl -b -1——-b是boot-1是上一次启动对比两次启动差异。查内核消息journalctl -k—— 等价于dmesg但格式更友好。导出为文本journalctl -xb /tmp/boot-log.txt—— 把日志导出用VS Code搜索关键词比终端里less强。注意journalctl默认只保留最近三次启动日志。如果要永久保存编辑/etc/systemd/journald.conf取消注释#Storagepersistent并创建/var/log/journal目录否则-b -2可能查不到。4.2 “重启”不是万能解药什么时候该重启什么时候该忍住新手有个通病一出问题就想reboot。但有些故障重启会让它更糟。该立刻重启的情况内核panic、硬件驱动死锁dmesg里大量watchdog: BUG: soft lockup、网络栈完全僵死ping不通网关ss -tuln无响应。该忍住重启的情况磁盘I/O错误dmesg里出现end_request: I/O error说明硬盘可能要挂了。此时重启可能让文件系统彻底损坏。正确做法是umount -l /mnt/datalazy unmount然后smartctl -a /dev/sda查SMART健康度。数据库崩溃MySQL/PostgreSQL报InnoDB: Database page corruption重启可能触发崩溃恢复失败。应先mysqld --innodb-force-recovery1尝试启动再dump数据。容器网络异常docker network inspect bridge显示IPAM: {Config: []}为空重启docker daemon会清空所有网络。应先docker network create mynet重建再docker network connect mynet container_name。我见过最惨的一次DBA发现MySQL慢kill -9所有mysql进程然后systemctl restart mysql。结果/var/lib/mysql/ibdata1被截断整个库无法恢复。后来用extundelete找回部分数据但三天的交易记录永远丢了。所以我的原则是对存储数据的服务重启前先问自己“我能保证数据不丢吗”4.3 “Live USB”不是摆设三个你从未用过的高级玩法Live USB不只是用来重装系统它是你的“系统急救舱”。玩法一离线查病毒。某客户服务器被植入挖矿木马top看CPU 100%但ps aux找不到可疑进程。我用Live USB启动sudo chroot /mnt进原系统然后sudo rkhunter --checkall、sudo clamscan -r /在离线状态下扫描木马无所遁形。玩法二恢复误删文件。rm -rf /usr/bin/这种灾难extundelete /dev/sda2 --restore-directory /usr/bin/能找回大部分。Live USB提供干净环境避免新写入覆盖已删除数据。玩法三硬件诊断平台。Live USB自带memtest86内存测试、smartmontools硬盘健康、stress-ngCPU压力测试。不用装任何软件插上就能测。提示别用随便下载的Live ISO。我只用Ubuntu 22.04 LTS和SystemRescueCD。前者软件新后者专为救援设计内置gparted、testdisk、photorec全套工具。4.4 “备份”不是口号三种零成本、高可靠备份方案所有故障修复的前提是你有备份。但很多团队说“我们有备份”结果真出事备份是半年前的。方案一rsync增量备份到NAS。每天凌晨2点执行rsync -av --delete --exclude/proc/* --exclude/sys/* --exclude/dev/* / rootnas:/backup/server1/$(date %Y%m%d)用--link-dest实现硬链接去重节省90%空间。方案二Btrfs快照。如果根分区是Btrfssudo btrfs subvolume snapshot / /snapshots/root-$(date %Y%m%d)秒级创建快照sudo btrfs subvolume delete /snapshots/root-old秒级回滚。方案三Git管理配置文件。/etc/、/home/username/.config/用git管理cd /etc git init git add . git commit -m initial # 设置cron每天自动commit我坚持一个原则备份必须可验证。每周五下午我会随机挑一台服务器用备份数据在测试机上rsync还原然后systemctl daemon-reload systemctl start nginx确保服务能起来。不能只看备份脚本“exit code 0”那只是证明脚本跑完了不是备份成功了。5. 经验沉淀从“修好”到“防住”我的三道防线体系修好一次故障只能算合格让同类故障永不发生才算专业。我给自己和团队立了三道防线层层递进把“救火队员”变成“防火专家”。5.1 第一道防线启动前的“体检清单”每次服务器上线、内核升级、硬件更换必须执行这份清单10分钟搞定杜绝80%的启动故障。[ ]固件检查sudo dmidecode -t bios确认BIOS版本查厂商公告是否有已知bugsudo smartctl -a /dev/sda | grep Power_On_Hours确认硬盘使用时长5000小时。[ ]启动项验证sudo efibootmgr -vUEFI或sudo grub-install --recheck /dev/sdaBIOS确认GRUB已正确安装。[ ]initramfs完整性sudo lsinitramfs /boot/initrd.img-$(uname -r) | wc -l对比上次升级行数不应骤减sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep modules确认关键驱动存在。[ ]fstab语法检查sudo findmnt --verify自动检查/etc/fstab语法和挂载点有效性。这份清单我做成一个脚本/usr/local/bin/preboot-check.sh上线前sudo bash /usr/local/bin/preboot-check.sh输出全是OK才能交付。5.2 第二道防线启动中的“黄金三分钟”监控系统启动过程前180秒决定生死。我部署了一个轻量级启动监控。原理利用systemd-analyze和journalctl在启动完成后自动抓取关键指标。实现在/etc/systemd/system/startup-monitor.service里[Unit] DescriptionStartup Monitor Aftermulti-user.target [Service] Typeoneshot ExecStart/usr/local/bin/monitor-startup.sh RemainAfterExityes [Install] WantedBymulti-user.targetmonitor-startup.sh内容#!/bin/bash # 记录启动总时间 systemd-analyze /var/log/startup/time.log # 记录耗时最长的5个服务 systemd-analyze blame | head -5 /var/log/startup/blame.log # 记录启动失败的服务 systemd-analyze verify 21 /var/log/startup/verify.log # 发送告警如果失败 if grep -q ERROR
阅读完成 · 觉得有帮助？
