如何三招帮你排查Linux中的硬件问题

如何三招帮你排查Linux中的硬件问题,第1张

下列贴士帮助你更快速更轻松地为 Linux 中的硬件排查故障。许多不同的因素可能导致Linux硬件出现问题;在你开始尝试诊断之前,了解最常见的问题以及最有可能找到原因的环节是明智之举。

Linux服务器在许多不同类型的基础架构中运行关键任务型业务应用程序,包括物理机、虚拟机、私有云、公共云和混合云。对于 Linux系统 管理员来说,了解如何管理Linux硬件基础架构很重要,包括与网络和存储有关的软件定义功能、Linux容器和Linux服务器上的多个工具。

排查并解决Linux上与硬件有关的问题可能需要一些时间。连经验丰富的系统管理员有时也要花几小时来解决莫名其妙的软硬件问题。

下列贴士帮助你更快速更轻松地为Linux中的硬件排查故障。许多不同的因素可能导致Linux硬件出现问题在你开始尝试诊断之前,了解最常见的问题以及最有可能找到原因的环节是明智之举。

1.快速诊断设备、模块和驱动程序

故障排查的第一步通常是显示Linux服务器上安装的硬件列表。你可以使用ls命令获取硬件的详细信息,比如lspci、lsblk、lscpu和lsscsi。比如说,这是lsblk命令的输出结果:

# lsblk

NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

xvda    202:0    0  50G  0 disk

├─xvda1 202:1    0   1M  0 part

└─xvda2 202:2    0  50G  0 part /

xvdb    202:16   0  20G  0 disk

└─xvdb1 202:17   0  20G  0 part

如果ls命令没有显示任何错误,使用初始化进程(比如systemd)查看Linux服务器的运行状况。systemd是启动用户空间、控制多个系统进程的最流行的初始化进程。比如说,这是systemctl status命令的输出结果:

# systemctl status

● bastion.f347.internal

    State: running

     Jobs: 0 queued

   Failed: 0 units

    Since: Wed 2018-11-28 01:29:05 UTC 2 days ago

   CGroup: /

           ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 21

           ├─kubepods.slice

           │ ├─kubepods-pod3881728a_f2af_11e8_af77_06af52f87498.slice

           │ │ ├─docker-88b27385f4bae77bba834fbd60a61d19026bae13d18eb147783ae27819c34967.scope

           │ │ │ └─23860 /opt/bridge/bin/bridge --public-dir=/opt/bridge/static --config=/var/console-config/console-c

           │ │ └─docker-a4433f0d523c7e5bc772ee4db1861e4fa56c4e63a2d48f6bc831458c2ce9fd2d.scope

           │ │   └─23639 /usr/bin/pod

2.深入研究多个日志

dmesg让你可以搞清楚内核的最新信息中的错误和警示内容。比如说,这是dmesg | more命令的输出结果:

# dmesg | more

....

[ 1539.027419] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[ 1539.042726] IPv6: ADDRCONF(NETDEV_UP): veth61f37018: link is not ready

[ 1539.048706] IPv6: ADDRCONF(NETDEV_CHANGE): veth61f37018: link becomes ready

[ 1539.055034] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[ 1539.098550] device veth61f37018 entered promiscuous mode

[ 1541.450207] device veth61f37018 left promiscuous mode

[ 1542.493266] SELinux: mount invalid.  Same superblock, different security settings for (dev mqueue, type mqueue)

[ 9965.292788] SELinux: mount invalid.  Same superblock, different security settings for (dev mqueue, type mqueue)

[ 9965.449401] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[ 9965.462738] IPv6: ADDRCONF(NETDEV_UP): vetheacc333c: link is not ready

[ 9965.468942] IPv6: ADDRCONF(NETDEV_CHANGE): vetheacc333c: link becomes ready

....

你还可以查看/var/log/messages文件中的所有Linux系统日志,在这里找到与特定问题有关的错误。如果你对硬件进行改动,比如挂载额外磁盘或添加以太网网卡,有必要通过tail命令实时密切关注信息。比如说,这是tail -f /var/log/messages命令的输出结果:

# tail -f /var/log/messages

Dec  1 13:20:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa

Dec  1 13:20:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain cluster.local

Dec  1 13:21:03 bastion dnsmasq[30201]: setting upstream servers from DBus

Dec  1 13:21:03 bastion dnsmasq[30201]: using nameserver 192.199.0.2#53

Dec  1 13:21:03 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa

Dec  1 13:21:03 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain cluster.local

Dec  1 13:21:33 bastion dnsmasq[30201]: setting upstream servers from DBus

Dec  1 13:21:33 bastion dnsmasq[30201]: using nameserver 192.199.0.2#53

Dec  1 13:21:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain in-addr.arpa

Dec  1 13:21:33 bastion dnsmasq[30201]: using nameserver 127.0.0.1#53 for domain cluster.local

3.分析网络功能

你可能在复杂的网络环境中有成千上万个云原生应用程序为业务服务提供服务这些可能包括虚拟化、多云和混合云。这意味着你应该分析网络连接是否正常运行,这是故障排查的一部分。分析Linux服务器中网络功能的实用命令包括ip addr、traceroute、nslookup、dig和ping等。比如说,这是ip addr show命令的输出结果:

# ip addr show

1:

lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000

    link/ether 06:af:52:f8:74:98 brd ff:ff:ff:ff:ff:ff

    inet 192.199.0.169/24 brd 192.199.0.255 scope global noprefixroute dynamic eth0

       valid_lft 3096sec preferred_lft 3096sec

    inet6 fe80::4af:52ff:fef8:7498/64 scope link

       valid_lft forever preferred_lft forever

3:

docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default

    link/ether 02:42:67:fb:1a:a2 brd ff:ff:ff:ff:ff:ff

    inet 172.17.0.1/16 scope global docker0

       valid_lft forever preferred_lft forever

    inet6 fe80::42:67ff:fefb:1aa2/64 scope link

       valid_lft forever preferred_lft forever

....

结束语

Linux硬件故障排查需要具备相当扎实的知识,包括如何使用功能强大的命令行工具、解读系统日志。你还应该知道如何诊断内核空间,可以在内核空间找到许多硬件问题的根本原因。请记住,Linux中的硬件问题可能由许多不同的方面引起,包括设备、模块、驱动程序、BIOS、网络,甚至是旧硬件故障。

查看/var/log/message

dmesg |egrep "sd|eth/memory/disk"

cat /var/log/messages |grep -i fail

dmesg |grep -i err

检查硬盘是否正常

smartctl简单用法

smartctl -A /dev/sda 查看硬盘的详细信息

smartctl -a <device>检查该设备是否已经打开SMART技术。

smartctl -s on <device>如果没有打开SMART技术,使用该命令打开SMART技术。

smartctl -t short <device>后台检测硬盘,消耗时间短;

smartctl -t long <device>后台检测硬盘,消耗时间长;

smartctl -C -t short <device>前台检测硬盘,消耗时间短;

smartctl -C -t long <device>前台检测硬盘,消耗时间长。其实就是利用硬盘SMART的自检程序。

smartctl -X <device>中断后台检测硬盘。

smartctl -l selftest <device>显示硬盘检测日志。

smartctl -l error <device>显示硬盘错误汇总。

内存可以看这个日志

/var/log下的mcelog

如果内存有问题就会出现下面的日志信息

Corrected error

MCi_MISC register valid

MCi_ADDR register valid

MCA: MEMORY CONTROLLER RD_CHANNELunspecified_ERR

Transaction: Memory read error

Memory read ECC erro

这篇教程的诞生过程实在相当纠结。很长时间以来我一直在考虑要不要写这么一篇东西,最主要的原因在于对硬件相关问题进行故障排查可能是计算机管理领域最棘手的工作。即使是经验相当丰富的用户有时也会遇上自己搞不定的状况,并在试图解决那些微妙、古怪、难以捉摸甚至无法确定的软硬件冲突困境时碰上钉子。想在网络上寻找答案?我们找到的很可能是上万个无关主题,最终在空荡荡的论坛上孤独徘徊、耗尽余生。不过就个人来说,我自认为算是个自负的极客、对技术难题和写作手法都有相当的信心。今天我打算尽量与大家分享一些实用的技巧与处理方法,希望有助于读者朋友理解、查明并最终搞定硬件难题--无论您使用的是Linux设备还是其它什么平台。这篇教程无法保证100%有效,其中的某些方法也可能不太容易掌握,但它还是能起到一些作用。请大家随我一起探寻硬件故障中的奥秘吧。 硬件故障类型在开始着手诊断硬件问题之前,我们首先需要调整预期、充分了解工作中可能遇到的硬件故障类型,这一点非常重要。最后,大家还必须掌握硬件故障的实际表现形式。硬件无法工作最常见的故障源自电子设备中的某一部分发生损坏,但例外情况同样时有发生。如果大家的电源出了问题,设备当然没办法启动,这个道理非常简单。除此之外,显卡、声卡甚至记忆棒都可能在关键时刻挂掉,并带来各种各样的奇怪表现。在这种情况下,系统也许仍能通过BIOS自检并进入 *** 作系统,甚至允许用户进行一定程度的正常 *** 作。而在某些情况下,我们可能会直接感受到设备故障,例如屏幕分辨率突然变得非常低--这肯定是因为显卡驱动程序无法正常工作或者听音乐时没有声音,那就是声卡的问题。在某些情况下, *** 作系统还可能直接d出错误提示信息。硬件的不稳定性故障不稳定性是我们面临的最困难、也最不容易确诊的故障类型之一。如果大家的硬件仅有某一部分发生损坏,那么整体设备也许仍能正常运转,只在特定情况下偶尔出现问题。这往往令用户摸不着头脑,无法把异常状况与对应设备联系到一起,从而得出正确结论。另外,即使是同一故障也可能存在多种表现形式,它们彼此之间看似毫无关联,但足以把用户折磨得死去活来。某些类型的错误甚至不会影响设备的正常功能,但它们却有可能偷偷导致数据损坏或设备整体性能下降。这类问题相当阴险,因为我们往往习惯于将其归罪于 *** 作系统损坏或软件冲突。举例来说,如果我们的记忆棒中存在少数损坏单元,使大家在访问并使用这些存储空间时发生段错误,各位打算怎么办?再有,我们可能会把系统内核崩溃与某些软件挂上钩,但其真正根源或许在于内存故障或总线错误,您想到了吗?另一个很好的例子就是三年前我在自己老款T61设备上遭遇的无线/笔记本问题。我专门用来玩游戏的发烧级台式机还碰到过由地线引发的故障。固件/驱动程序故障驱动程序故障常常表现得像是硬件出了问题,但不同之处在于其发作状况比较稳定、不像硬件那样时好时坏。通常情况下,软件问题导致的状况比较一致且能够再现。在某些情况下,我们的驱动程序甚至无法与硬件进行通信而在另一些情况下,存在bug的驱动程序会令设备以意料之外的方式运作。有时候这类问题还会转化成全局功能缺失,例如内核崩溃、黑屏、白屏以及其它各种奇怪的故障。其它注意事项大家还必须意识到,某些系统可能会锁定BIOS以防止我们使用某些硬件组件或功能,或者是出于某种目的而禁用这些组件。在后面的文章中我们将进一步讨论BIOS的相关话题。最后,大家可能会在无意中将那些设计上存在冲突的硬件组件放在一起工作。某些供应商生产的硬件也许只针对某款特定 *** 作系统,因此我们无法从官方得到任何其它系统平台上的驱动程序支持。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/7631083.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-08
下一篇 2023-04-08

发表评论

登录后才能评论

评论列表(0条)

保存