我使用 GNU/Linux Mint 18.3 和内核版本 4.10.0-42。在过去的几周里,我的系统偶尔会挂起,没有任何迹象表明即将出现问题(我已经注意到了)。
我尝试过切换内核版本(之前有过 4.4.0 和 4.8.0),但无济于事。
我该怎么做才能解决或避免这个问题?
附加信息
- 我的系统的 BIOS 是“ASUS UEFI BIOS 3016”。
- 我的根目录位于 SSD 上,没有太多写入操作
- 在硬件发生某些变化后,系统不会立即出现挂起现象。
- 当我在电脑前时,这种情况似乎从未发生过,当我离开/睡觉时,这种情况总是或几乎总是发生。但同样,并非总是如此,也就是说,大多数日子里这种情况不会发生。
- 我使用板载显卡运行 XFCE,但我还有一台不用于显卡的 nVIDIA GTX 650 Ti(当这些挂起发生时,它处于空闲状态)。nVIDIA 驱动程序版本现在为 387.26。
- 当发生挂起时,显示器继续显示最后一幅图像,但没有任何响应。++Ctrl不起作用,并且计算机不响应网络流量。AltFn
我的机器
(我将根据要求在下面添加任何其他信息。)
/var/log/syslog
上次挂起之前和之后:
Jan 7 23:09:55 my_pc smartd[966]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 70 to 69
Jan 7 23:39:55 my_pc smartd[966]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 69 to 68
Jan 8 00:03:48 my_pc rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="947" x-info="http://www.rsyslog.com"] start
Jan 8 00:03:48 my_pc rsyslogd: rsyslogd's groupid changed to 108
Jan 8 00:03:48 my_pc rsyslogd: rsyslogd's userid changed to 104
/var/log/syslog
倒数第二次挂起之前和之后:
Jan 7 16:07:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 111 to 112
Jan 7 16:37:49 my_pc smartd[933]: Device: /dev/sdc [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 58 to 59
Jan 7 16:37:49 my_pc smartd[933]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 41
Jan 7 16:37:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111
Jan 7 17:07:49 my_pc smartd[933]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 69 to 70
Jan 7 17:07:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 111 to 112
Jan 7 17:37:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111
Jan 7 17:56:58 my_pc systemd[1]: Starting Daily apt download activities...
Jan 7 17:57:04 my_pc systemd[1]: Started Daily apt download activities.
Jan 7 17:58:05 my_pc inadyn[1376]: .
Jan 7 17:58:05 my_pc inadyn[1376]: Checking for IP# change, connecting to ip1.dynupdate.no-ip.com(34.196.162.199)
Jan 7 17:58:05 my_pc inadyn[1376]: No IP# change detected, still at 11.22.33.44
Jan 7 18:07:49 my_pc smartd[933]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 70 to 69
Jan 7 19:09:55 my_pc rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="967" x-info="http://www.rsyslog.com"] start
Jan 7 19:09:55 my_pc rsyslogd: rsyslogd's groupid changed to 108
Jan 7 19:09:55 my_pc rsyslogd: rsyslogd's userid changed to 104
温度/dev/sdd
记录很奇怪。你知道,我不知道有一个sdd
。也就是说,sda
是我的 SSD,sdb
是sdc
磁性 HDD,/dev/sr0
是 DVD 播放器。/dev/sdd
甚至不作为 中的特殊文件存在/dev
。
其他日志中的行:
auth.log
显示一些中国 IP 尝试以 root 身份通过 SSH 进入我的机器,例如:
Jan 7 23:39:53 my_pc sshd[19697]: message repeated 3 times: [ Failed password for root from 218.65.30.53 port 51732 ssh2]
Jan 7 23:39:56 my_pc sshd[19697]: Failed password for root from 218.65.30.53 port 51732 ssh2
Jan 7 23:39:59 my_pc sshd[19697]: Failed password for root from 218.65.30.53 port 51732 ssh2
Jan 7 23:39:59 my_pc sshd[19697]: error: maximum authentication attempts exceeded for root from 218.65.30.53 port 51732 ssh2 [preauth]
Jan 7 23:39:59 my_pc sshd[19697]: Disconnecting: Too many authentication failures [preauth]
Jan 7 23:39:59 my_pc sshd[19697]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65.30.53 user=root
但我不认为这有关系,因为挂起后也发生了这种情况。在我上面提到的磁盘相关消息和挂起之间,其他日志上没有其他行。
答案1
可能是您的某个驱动器断开连接后重新连接,但被检测为新设备。根据我使用 Linux 服务器的经验,如果旧设备未正确断开连接且内核仍保留其字母,则有时会发生这种情况,当它重新连接时会为其分配一个新字母。可能是您的某个驱动器出现故障或电缆未固定。这实际上取决于控制器及其处理设备的方式。
由于您说您发现机器已经挂起,而您无法真正查看它发生了什么,我建议您编写一个小的 bash 脚本,不断提取有关所有驱动器的信息并将其写入文件,最好是写入您确定可以正常工作的驱动器之一,否则如果您尝试在故障驱动器上写入,则可能无法写入。脚本可能类似于:
#!/bin/bash
date
echo "Starting device data dump"
for drive in sda sdb sdc sdd
do
echo "Dumping data for drive ${drive}"
fdisk -l
smartctl -a /dev/${drive}
dmesg -T | tail -n50
done
echo "Ended device data dump"
将其放入每分钟运行一次的 cron 中,并将输出写入文件
crontab -e
Crontab 行添加:
* * * * * /usr/local/bin/logcommand.sh >> /var/log/disk-problem.log
手动检查文件中的内容。您应该能够看到 sdd 的智能数据,如型号、品牌、序列号,并将其与其他驱动器进行比较。如果其中一个断开连接,则会出现匹配,如果没有,您仍然应该能够获取有关该神秘 sdd 驱动器及其可能的信息。
另外,检查你的 dmesg 是否写入 /var/log 中的某个文件。dmesg 应该打印设备断开连接和检测信息。
附言:此外,由于当您发现您的机器挂起时,它可能是您的根设备,它会给您带来问题,因为它拥有基本系统,如果没有它,机器就无法运行。
答案2
我不知道这是否有帮助,但我也有类似的情况。该系统是运行 Linux Mint 18.3 (XFCE) 的 Intel NUC,配备 8GB RAM 和 M2 SSD,因此与 OP 非常相似。
我的问题只在运行 Thunderbird 时出现。我将所有 Thunderbird 数据导向另一台用作服务器的 Linux Mint 计算机。小型 Thunderbird 帐户可以正常工作,但较大的帐户会导致系统变得不稳定,Thunderbird 根本无法运行。
Linux Mint 18.3 (XFCE) 附带 Linux 内核 4.10.0-38,在我的系统上运行良好 - Thunderbird 在其他系统上运行良好。但是,如果我使用内置的 Mint 升级包将 Linux 内核升级到 4.10.0-42,Thunderbird 会导致上述问题。
我必须强调,这个问题(使用较新的内核 - 4.10.0-42)仅发生在我的 NUC 电脑上 - 其他系统在升级内核后运行良好。
我的临时解决方案是坚持使用 4.10.0-38 内核,并在使用之前对任何升级进行全面测试。