私のLinuxシステムは時々不思議なことにハングします。私に何ができる？

私は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 + Alt + Fn 動作しません、そしてコンピュータはネットワークトラフィックに応答しません。

私の機械

（必要に応じて、以下に追加情報を追加します）

/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 最後から2番目のハングの前後

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サーバでの私の経験では、これは古いデバイスが正しく切断されず、カーネルがまだその文字を保持していて再接続したときに新しい文字を与える場合に時々起こります。 ドライブの1つに問題があるか、ケーブルが固定されていない可能性があります。 これは本当にコントローラとそれがデバイスをどのように扱うかにかかっています。

あなたはマシンがすでにハングしていて、何が起こったのか確かめることができないと言っているので、すべてのドライブについての情報を常に引っ張ってそれをファイル、好ましくはドライブの1つに書き込むあなたは確かに仕事をしている、そうでなければあなたがそれを失敗したドライブに書き込もうとしても書かれないかもしれません。スクリプトは次のようになります。

#!/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のスマートなデータを見て、あなたの他のドライブとそれを比較することができるはずです。それらのうちの1つが切断されているならば、あなたはまだその神秘的なsddドライブとそれが何であるかについての情報を得ることができるはずです。

また、dmesgが/ var / log内のファイルに書き込まれているかどうかも確認してください。 dmesgはデバイスの切断と検出を表示します。

シモンズ：また、あなたがそれを見つけたときにあなたのマシンがハングしているので、それはおそらくベースシステムを保持し、それなしではマシンが機能できないのであなたに問題を与えるあなたのルートデバイスです。

これで解決するかどうかはわかりませんが、状況は似ています。 このシステムは、8Gb RAMとM2 SSDを搭載したLinux Mint 18.3（XFCE）を実行するIntel NUCで、OPと非常によく似ています。

私の問題はThunderbirdを実行しているときにのみ現れます。私はすべてのThunderbirdデータを私がサーバーとして使っている別のLinux Mintコンピュータに向けています。小さなThunderbirdアカウントは（正しく）動作しますが、大きなアカウントはシステムを不安定にし、Thunderbirdは実際にはまったく動作しません。

Linux Mint 18.3（XFCE）はLinux Kernel 4.10.0-38に同梱されており、これは私のシステムでは問題なく動作します - Thunderbirdは他のシステムでも動作します。 しかし、内蔵のMintアップグレードパッケージを使ってLinux Kernelを4.10.0-42にアップグレードすると、Thunderbirdは上記の問題を引き起こします。

私はこの問題（新しいKernel - 4.10.0-42を使う）が私のNUCコンピュータでのみ起こることを強調しなければなりません - 他のシステムはアップグレードされたKernelでうまく動作します。

私の暫定的な解決策は4.10.0-38カーネルを使い続け、使用する前にアップグレードを完全にテストすることです。