- 一个好的 Linux 诊断程序是基于收集数据、分析日志，并以有序和可逆的方式应用更改。
- 系统工具（journalctl、dmesg、smartctl、lm-sensors、fsck、ethtool、htop 等）可以帮助您定位软件和硬件故障。
- 了解错误类型（内核、文件系统、网络、应用程序和硬件）有助于在每种情况下选择合适的测试。
- 备份、定期更新和完善的文档可以降低风险，并使未来出现的问题更容易、更快地得到解决。
如果你每天都使用 Linux，迟早会遇到一些奇怪的问题：系统无法启动、服务无故崩溃、Wi-Fi 连接频繁断开，或者硬盘发出令人担忧的噪音。这些问题并非灾难，而是绝佳的机会，让你了解系统内部的工作原理，并建立一套可靠的 Linux 问题诊断方法。
与其他系统（例如 Windows 故障排除程序或 DISM/SFC 等命令）更自动化的方法不同，Linux 提供了一个强大的诊断工具生态系统，包含详细的日志和监控实用程序。关键不在于记住命令，而在于理解整个过程：如何收集信息、如何解读信息以及如何采取行动而不使情况变得更糟。
Linux 问题诊断的一般方法
Linux 故障排除不应该是“随便碰碰看看会发生什么”的随意做法，而应该是一个基于逻辑和观察的有序且可重复的过程。越系统化，就越能快速找到根本原因，也越不容易在过程中破坏其他东西。
首先，在进行任何操作之前，务必尽可能多地收集有关错误的信息。这意味着要记下具体的错误信息、出现时间以及错误发生前你正在进行的操作。诸如“更新后出现”、“仅在运行此程序时出现”或“连接此 USB 设备时出现”之类的细节对于故障诊断至关重要。
还值得注意的是，问题是否始终可复现，还是间歇性出现。了解是否可以人为触发错误，将有助于您在可控的环境下测试解决方案，并确认其是否真正有效。
在收集数据时，必须发挥你最敏锐的观察力：屏幕上的信息、主板诊断指示灯、磁盘或风扇发出的异常机械噪音、烧焦的气味、摸起来过热的区域……你的感官（视觉、听觉、嗅觉和触觉）也是诊断工具包的一部分，尤其是在你怀疑存在物理硬件问题时。
掌握了初步信息后，下一步合乎逻辑的做法是缩小故障源的范围：是软件相关问题（内核、文件系统、服务、应用程序）、配置相关问题（网络、权限、驱动程序），还是硬件相关问题（内存、磁盘、温度、电源、网卡、显卡等）？这种分类将指导您在每种情况下选择合适的工具。
Linux 问题解决的关键原则
好的诊断依赖于几个基本原则，这些原则应该尽快牢记于心。首先是系统地收集数据：仅仅说“我的Wi-Fi不能用”是不够的；你需要知道是否存在网络中断，问题是否仅限于你的设备，是影响特定服务还是所有连接，系统日志显示了什么，是否存在驱动程序错误等等。
下一步是使用合适的工具分析收集到的信息。Linux 提供了非常详细的系统日志、资源监控命令以及特定的网络和硬件实用程序。通常的做法是结合使用多个信息源：例如，使用journalctl和dmesg查看内核和服务消息，使用top 或 htop检查系统负载，以及使用ping、ss 或 tcpdump等网络工具查看连接情况。
一旦有了合理的假设，就该认真地测试各种解决方案了。这意味着每次只实施一项更改，检查结果，如果不行就撤销。千万不要同时进行多项更改，因为如果问题消失了，你就不知道是哪一项更改解决了问题；如果问题恶化了，你也搞不清楚究竟是什么导致了问题。
另一个常被忽视的重要支柱是文档记录。记录你执行的命令、修改的文件以及得到的结果，可以让你复现成功的解决方案，与他人分享，并避免几周后浪费时间重复研究同样的问题。此外，你还可以通过在论坛或维基上分享笔记来为 Linux 社区做出贡献。
最后，请记住简洁原则。系统越复杂，服务、守护进程和抽象层层叠加，出错的概率就越大。尽可能保持系统简洁明了：减少不必要的服务、冗余软件和复杂的层级。这样可以缩小问题出现的范围，使故障诊断更加容易。
在进行任何操作之前，请先做好系统准备：备份和更新
在开始修改配置、修复文件系统或更新内核之前，您应该确保万一出现问题，您可以恢复数据。Linux中的备份是您的安全保障，尤其是在您将要操作关键分区、磁盘或服务时。
使用rsync进行增量备份是一个非常灵活的选择。它通常会结合一些选项，例如-a（文件模式，保留权限、所有者和日期）、-v（垂直输出）以及用于跟踪备份进度的进度参数。重要的是要有一个可访问且空间充足的目标目录，最好位于外部驱动器或与系统分区分离的独立分区上。
如果您希望将所有内容打包到一个文件中，可以使用tar命令，并添加-c （用于创建归档文件）、-z（用于使用 gzip 压缩）、-v（用于查看进度）和-f（用于指定生成的文件名）等参数。之后，建议使用 tar 命令列出备份文件的内容，以验证备份文件的完整性，确保备份文件未损坏。
至于备份目标位置，关键在于备份文件不应与要保护的系统位于同一磁盘上。外置 USB 硬盘、使用 rclone 等工具存储到云存储，或者使用单独的分区都是明智的选择。这样做的目的是，如果主磁盘发生故障或系统无法使用，您可以利用备份文件进行恢复。
另一个强烈建议的初步步骤是更新系统。许多问题只需安装修正后的软件包和内核版本即可解决。在 Debian/Ubuntu 系统中，通常的做法是先运行软件包列表更新命令，然后更新已安装的软件包，并检查输出结果以查找错误。在 Fedora 及其衍生发行版中，软件包更新命令的作用类似，Arch Linux 中的 ` pacman -Syu`命令也是如此。由于 Arch Linux 采用滚动发布模式，保持系统更新尤为重要。
基本硬件检查：CPU、内存、硬盘和传感器
当系统运行缓慢、随机死机或无故重启时，不要立即断定是软件问题。通常，问题的根源在于硬件老化、温度过高或内存模块故障。
要了解硬件概况，您可以使用诸如`lshw`（详细设备信息）、`lsblk`（磁盘和分区列表）之类的命令，或者使用诸如`dmidecode`之类的专用工具，它可以从 BIOS/UEFI 中提取数据。例如，` dmidecode -t memory`将显示已安装的 RAM 模块信息（DDR 类型、容量等），而 ` dmidecode -t 16`将显示主板支持的最大内存容量。有关内存管理的更多详细信息，请参阅Linux 中的内存管理。
如果想快速了解内存组件的概况，`lshw -short -C memory`可以提供简洁的摘要；而`dmidecode --type memory | grep -E "Speed|Configured Clock Speed"`则可以让您比较内存模块的标称速度和芯片组配置的速度。例如，这可以帮助您发现，某个支持 3200 MT/s 的内存模块由于与速度较慢的内存模块共享通道，实际运行速度只有 2400 MT/s。
温度监控是另一个关键方面。借助lm-sensors软件包，您可以从 CPU 和其他主板传感器获取温度和电压读数。安装后，建议运行`sudo sensors-detect`来检测并激活所有可用的传感器，然后使用类似`watch -n 2 sensors` 的命令来实时监控 CPU 或内存是否过热。
对于硬盘（SATA HDD 或 SSD），像hddtemp这样的工具可以读取设备温度，而psensor软件包或像xsensors这样的图形工具则可以提供温度的历史数据和图形视图。例如，如果发现 SSD 持续在其温度范围的极限附近运行，则明显表明散热或负载存在问题。
磁盘和文件系统状态诊断
磁盘故障和文件系统错误会导致无数问题，从文件损坏到系统无法启动。Linux 提供了多种实用程序来检查磁盘的物理状态和文件系统的逻辑完整性。
首先，您可以使用诸如`lsblk -fm`或`fdisk -l`之类的命令列出已连接的存储设备，如果需要，可以过滤掉环回虚拟驱动器。这样，您就可以验证系统识别了哪些磁盘和分区、它们的文件系统以及挂载点。
smartmontools套件（包含 smartctl 命令）对于充分利用现代硬盘内置的 SMART 技术至关重要。首先，您需要使用正确的激活命令确保硬盘已启用 SMART 功能。之后，您可以查看诸如Power_On_Hours之类的属性，了解硬盘的运行时间，或者运行smartctl -H 命令快速评估设备的健康状况。
除了即时检查外，smartctl 还允许您运行自动诊断测试：快速检查的短测试和更全面的长时间或扩展测试。之后，您可以使用显示所有磁盘信息的命令查看结果和详细属性。如果您检测到重新分配的扇区、错误数量增加或“故障前期”状态，就应该考虑更换该磁盘了。
另一个重要的工具是fsck，它可以检查并修复文件系统中的逻辑错误。如果分区包含重要数据，运行 fsck 会带来一定的风险，因此备份至关重要。您可以将其与badblocks结合使用，以定位并标记坏扇区，从而避免系统将来使用这些扇区。但是，如果出现大量坏块，建议更换磁盘。
要诊断空间问题，`df -h` 命令会显示分区使用情况（以 GB 为单位），而`df -i`命令则会显示已占用 inode 的百分比。完全有可能出现有 GB 的可用空间，但 inode 占用率却达到 100% 的情况，这会导致即使有可用空间，创建新文件时也会出错。这种情况在处理数百万个小文件的服务器上很常见。
内存分析：ECC错误、测试和稳定性
内存故障会导致一系列问题，从简单的随机崩溃到静默的数据损坏。如果您的系统使用ECC内存，硬件本身可以纠正某些错误，但这并不意味着您可以高枕无忧：被纠正的错误恰恰表明内存模块开始出现故障。
Linux 系统可以通过EDAC子系统公开这些信息。安装相应的模块后，您将在系统日志中看到区分已纠正错误 (CE) 和不可纠正错误 (UE) 的消息。前者表示硬件已修复损坏的位，而后者通常会导致内核立即崩溃，以防止将损坏的数据写入磁盘。
检查内核是否记录了 EDAC 错误的一个简单方法是查看`dmesg | grep EDAC`的输出。如果在同一个模块中发现重复的 EDAC 错误，这清楚地表明应该更换哪个内存块，以免这些错误变得无法修复。有关高级技巧和工具，请参阅这篇Linux 内存调试指南。
为了进行更彻底的测试，通常会使用像memtest86这样的外部工具，这些工具需要从外部驱动器（U盘或其他类似设备）运行。这些工具会对内存进行密集的读写操作，以检测在正常使用情况下可能数月都难以察觉的错误。建议运行多次测试以确保结果的准确性。
您还可以使用压力测试等工具对系统进行一般性压力测试。这些工具会在指定时间内对 CPU、I/O 和内存进行负载测试，并观察是否出现崩溃、内核错误或内核恐慌等情况。如果系统在负载下可重复出现故障，则很可能是硬件问题（温度、电源、内存）或内核/驱动程序不稳定。
系统监控：CPU、进程、I/O 和 GPU
要了解机器在任何给定时刻的运行状况，您需要好的监控工具。Linux 提供了几个控制台实用程序，让您可以一目了然地看到哪些进程消耗的 CPU、内存、磁盘 I/O 或 GPU 使用率最高。
经典的`top`命令或其更友好的版本`htop`可以显示活动进程、CPU 使用率、内存使用率和平均负载。要专门监控每个进程的磁盘活动，`iotop`非常有用，而`nmon` 则在一个非常完整的文本界面中提供了多个子系统（CPU、内存、网络、磁盘）的全面概览。
在图形处理领域，GPU 使用率可能会成为运行图形密集型应用程序或加速计算任务的系统瓶颈。对于 Intel 显卡，intel-gpu-tools软件包包含诸如intel_gpu_top之类的命令，可以实时显示 GPU 负载、执行队列和内存使用情况。
如果您使用的是 NVIDIA 显卡，可以使用诸如gpustat之类的 Python 工具，或者像Glances这样的通用监控软件（需启用 GPU 支持），它们可以显示显存占用、GPU 使用率以及正在使用 GPU 的进程。对于 AMD Radeon GPU，像radeontop这样的工具也提供了类似的功能，可以显示芯片各个内部单元的使用情况条。
如果您怀疑图形驱动程序是问题的一部分（例如，进入图形环境时出错、使用合成器时崩溃等），建议您使用类似`lspci -vnn | grep VGA -A 12`、`lshw -C display`或`inxi -G`的命令检查已安装的显卡驱动程序，并确认您使用的是开源驱动程序、专有驱动程序还是过时的驱动程序。在 Ubuntu 等发行版中，您可以启用特定的图形驱动程序存储库（例如，Radeon 的存储库），并更新到针对您的 GPU 优化的更新版本。
网络诊断：网卡、丢包和配置
网络问题可能从“我没有连接”到“除了这项服务之外，其他所有服务都很慢”。为了避免不知所措，第一步是确定问题是出在您的计算机、本地网络还是互联网上。Linux 提供了多层工具来测试连接性、查看网卡统计信息和检测丢包，本IP 和 DNS 网络诊断指南将深入探讨这些检查和解决方案。
像ping这样的基本命令可以让你检查是否可以访问特定主机（例如，你的路由器或外部域名），而traceroute则会显示数据包到达目的地的路径，这有助于你查看数据包在哪一跳丢失。要查看哪些端口处于打开状态以及哪些进程正在使用这些端口，可以使用ss 命令，它是 netstat 的现代替代品，并提供列出活动 TCP/UDP 连接的选项。
当您怀疑问题出在网卡本身时，像ethtool这样的工具就显得尤为重要。通过显示详细统计信息的命令，您可以实时监控 RX/TX 错误、丢包、缓冲区问题或 FIFO 溢出，并可结合`watch` 命令不断刷新输出，从而检测丢包模式。
另一个非常直观的方法是使用`netstat -ni` （或同等的更现代的工具）检查接口错误计数器。您会看到成功接收和成功发送的数据包数量，以及丢包数量。如果丢包率（RX-DRP/RX-OK 或 TX-DRP/TX-OK 乘以 100）超过 0,2% 这样的小数值，则对连接性能的影响可能非常显著，有效速度可能会减半甚至更低。
新买的网卡由于出厂缺陷或设计缺陷，出现无法接受的错误率并不罕见。更换网卡型号并重复测试通常可以最终确认瓶颈在于网卡。因此，在指责网络服务提供商或路由器之前，获取信号丢失和错误率的客观数据至关重要。
最好使用`rfkill`等命令检查 Wi-Fi 或蓝牙等无线设备的状态，这些命令可以指示它们是否被软件或硬件阻止。要查看网络接口的制造商、型号和功能，可以使用`lshw -C network`或`inxi -Nx`命令，它们可以提供非常详细的信息；而`ethtool interface_name | grep -i speed`命令则可以显示网卡的连接速度（例如 10/100/1000 Mbps）。
Linux 中的系统日志和严重级别
系统日志就像你的历史记录：所有（或几乎所有）发生的事情都会被记录在那里。了解它们的工作原理以及如何筛选它们可以节省你大量时间。在基于 systemd 的现代系统中，journalctl是查询二进制日志的核心工具，而在更传统的系统中，你仍然可以在 /var/log 目录下找到文本文件。
最常见的日志文件包括/var/log/syslog和/var/log/messages（用于收集常规系统事件）以及/var/log/auth.log（用于记录身份验证相关事项）。您可以使用less和grep等工具按关键字（例如 error、fail、timeout 等）过滤这些日志文件。使用 systemd 日志时，您可以使用特定选项查看上次启动以来的消息，查看特定服务的日志，或按时间范围（例如，最近两小时）进行过滤。
`dmesg`命令会显示内核消息缓冲区，这对于检测硬件问题非常有用，例如驱动程序卸载、PCI 总线错误、内存警告等等。` -T`参数提供可读的时间戳，而按严重级别筛选则可以帮助您专注于最关键的问题。此外，` dmesg -w`可以让您实时查看生成的消息，这在连接/断开设备或怀疑内核崩溃前出现错误时非常实用。
消息按严重级别分类，帮助您确定优先级。级别从0（紧急）开始，表示可能导致崩溃或严重不稳定的极其严重的情况；依次为1（警报）、2（严重）和3（非严重错误）；再到警告（级别 4）、重要警报（级别 5）、信息性消息（级别 6）和调试消息（级别 7）。了解这些级别可以让您在日志非常冗长时过滤掉无关信息，专注于真正重要的内容。
使用grep命令处理管道可以让你从纯文本日志中提取特定级别的行，而 systemd 工具则提供了按优先级过滤日志的特定参数。掌握这些过滤器，就能让你在成千上万行日志中快速找到关键信息，而不是迷失在茫茫日志中。
Linux 系统中的错误类型包括：内核错误、文件系统错误、网络错误、应用程序错误和硬件错误。
为了准确诊断问题，了解所遇到的错误类型至关重要。Linux 问题大致可以分为内核错误、文件系统错误、网络错误、应用程序错误和硬件错误，尽管它们通常相互关联。
内核错误涵盖范围很广，从简单的警告到内核崩溃（kernel oops）和内核恐慌（kernel panic）等严重情况都有。内核崩溃是一种严重的故障，内核会终止导致错误的进程，但会尝试继续运行。它可能是内存不足、驱动程序故障、不兼容、数据损坏或程序错误等问题的征兆。如果问题影响到关键子系统，内核崩溃可能会升级为内核恐慌，这相当于其他系统中常见的蓝屏死机。
内核崩溃是一种“硬崩溃”：系统几乎完全冻结，屏幕上会显示一条错误信息（通常晦涩难懂），并且根据配置的不同，可能会强制系统自动重启。内核崩溃通常由无效的内存访问、关键驱动程序故障、根分区无法访问、严重的内存问题、初始化进程失败、initramfs 错误、内核安装不当或不受支持，以及不稳定的补丁程序等原因引起。内核本身可能会执行内存转储（内核崩溃转储）以供后续分析。
文件系统错误表现为无法挂载分区、出现损坏信息、文件无法读取或数据丢失。突然关机、断电、坏扇区或文件系统驱动程序中的错误都可能导致这些错误。这时，fsck、smartctl 以及您在进行任何更改之前所做的备份就显得尤为重要。
在网络领域，故障症状可能包括间歇性断线、传输速度慢、延迟高，甚至完全无法连接。故障原因包括配置错误（IP、路由、DNS、防火墙）、网卡驱动程序故障、Wi-Fi干扰、物理布线错误或网络路径上的某个环节拥塞。我们之前讨论过的网络诊断工具可以帮助我们定位故障发生的层级。
应用程序错误包括程序意外关闭、无法启动、显示缺少库的提示信息或无响应等。它们通常是由依赖项损坏、库版本不兼容、代码错误、脚本编写不佳或竞态条件引起的。诸如strace（用于跟踪系统调用）或lsof（用于查看进程的打开文件和网络连接）之类的工具可以提供有价值的信息。
最后，硬件故障的范围很广，包括连接器松动、线缆损坏、端口破损或灰尘堆积，以及过热、潮湿或老化导致的电子故障。这还包括组件之间的冲突（例如 IRQ、DMA 等）以及电源或性能问题（例如温度限制、内存不足、CPU 性能不足）。同样，结合您的感官、监控工具和压力测试，将有助于您确定是哪个物理组件出现了故障。
有序诊断过程的实用步骤
虽然每个问题都独一无二，但您可以遵循一套适用于几乎所有情况的“框架”步骤。第一步，正如前面提到的，是精确定义问题：哪里出了问题，从什么时候开始的，在什么条件下发生的，以及在此之前发生了什么变化（软件安装、更新、硬件更换等）。如果您能够可靠地重现故障，那就更好了。
第二步是查看系统状态和日志：使用journalctl和dmesg命令查找相关信息（尤其注意错误、严重或警报级别的消息），使用top/htop命令检查系统负载，使用内存使用情况命令检查可用内存，使用 df 命令检查磁盘使用情况，并查看受影响服务或应用程序的特定日志。搜索诸如 error、fail、panic 或 timeout 之类的关键字通常可以快速找到线索。
第三，建议查阅外部资源。例如，使用“Ubuntu 20.04 wifi 断开连接”这样的关键词进行搜索，通常可以找到论坛帖子、发行版的维基页面或错误报告，其中可能包含其他用户遇到的相同问题。别忘了查阅手册页（man）、官方文档、使用指南和维基页面；那句著名的“RTFM”（阅读手册）仍然是最好的建议之一。
一旦你有了几个假设，就可以进入测试阶段：重启特定服务、临时修改配置文件（并做好备份）、禁用内核模块、使用启动管理器中提供的另一个内核启动、测试另一个物理设备等等。关键在于逐一进行可逆且可控的更改，并在每一步之后检查问题是否仍然存在。
当你最终找到消除错误的解决方案时，还有最后一步，而这一步往往最容易被忽视：验证其稳定性并记录你的操作步骤。理想情况下，你应该重启计算机（如果问题影响了启动）或让系统在高负载下运行一段时间，检查日志中是否再次出现错误，并将解决方案记录在你的技术日志中。这些经验将帮助你预防问题再次发生，或者下次只需几分钟就能解决问题。
有了这套理念、工具和方法，Linux 不再是一个神秘的黑匣子，而变成了一个可以让你相当准确地诊断各种问题的环境，从简单的日志信息到内核崩溃或内存故障，都能轻松应对。这并非意味着要记住上千条命令，而是要内化一套系统化的方法，依靠文档和社区的力量，并且在出现问题时勇于深入探究其底层原理。
