web-dev-qa-db-ja.com

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

カーネルバージョン4.10.0-42でGNU/Linux Mint18.3を使用しています。過去数週間、時々私のシステムがハングし、(私が気付いた)次のトラブルの前に何の兆候もありません。

カーネルバージョンを切り替えてみましたが(以前は4.4.0と4.8.0でした)、役に立ちませんでした。

この問題を解決または回避するにはどうすればよいですか?

追加情報

  • 私のシステムのBIOSは「ASUSUEFIBIOS3016」です。
  • 私のルートは、書き込みアクションがあまり見られない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、sdbsdcは磁気HDD、/dev/sr0はDVDプレーヤーです。 /dev/sddは、/devに特別なファイルとしても存在しません。

他のログからの行:

auth.logは、rootとして私のマシンにSSHで接続しようとしているいくつかの中国のIPを示しています。例:

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

しかし、これはハングの後にも起こっているので、これは関連しているとは思いません。上記のディスク関連のメッセージとハングの間に、他のログに他の行はありません。

2
einpoklum

ドライブの1つが切断されてから再接続されたが、新しいデバイスとして検出された可能性があります。 Linuxサーバーでの私の経験では、古いデバイスが適切に切断されず、カーネルがまだその文字を保持している場合にこれが発生することがあり、再接続すると新しい文字が表示されます。ドライブの1つに障害があるか、ケーブルが固定されていない可能性があります。これは実際にはコントローラーとそれがデバイスを処理する方法に依存します。

マシンがすでにハングしていることに気づき、何が起こったのかを実際に確認することはできないと言うので、すべてのドライブに関する情報を絶えずプルしてファイル、できればドライブの1つに書き込む小さな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のスマートデータを確認し、他のドライブと比較できるはずです。それらの1つが切断されている場合は一致がありますが、そうでない場合でも、その不思議なsddドライブとそれが何であるかについての情報を取得できるはずです。

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

PS:また、あなたのマシンはあなたがそれを見つけたときにハングしているので、おそらくあなたのルートデバイスがあなたの問題を潜ります。なぜなら、もしそれがなければマシンは機能しなかったからです。

3
EvilTorbalan

これが役立つかどうかはわかりませんが、同じような状況にあります。システムはIntel NUC Linux Mint 18.3(XFCE)を実行し、8Gb RAMおよびOPと非常によく似たM2SSDです。

私の問題は、Thunderbirdを実行しているときにのみ表示されます。私はすべてのThunderbirdデータを、サーバーとして使用している別のLinuxMintコンピューターに転送します。小さな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カーネルに固執し、使用する前にアップグレードを完全にテストすることです。

1
Mike