Mein Linux-System hängt ab und zu geheimnisvoll. Was kann ich machen?

985
einpoklum

Ich verwende GNU / Linux Mint 18.3 mit der Kernel-Version 4.10.0-42. Seit einigen Wochen hängt mein System ab und zu, ohne dass irgendwelche Anzeichen für bevorstehende Probleme auftauchen.

Ich habe versucht, Kernel-Versionen zu wechseln (hatte zuvor 4.4.0 und 4.8.0), aber ohne Erfolg.

Was kann ich tun, um dieses Problem zu lösen oder zu umgehen?

Zusätzliche Information

  • Das BIOS meines Systems ist "ASUS UEFI BIOS 3016".
  • Mein Root befindet sich auf einer SSD, auf der nicht viel geschrieben wurde
  • Die Hänge traten (unmittelbar) nicht nach einigen Hardware-Problemen auf.
  • Das scheint nie zu passieren, wenn ich am eigentlichen Computer bin, immer oder fast immer, wenn ich weg bin / schlafe. Aber nicht immer, dh an den meisten Tagen passiert dies nicht.
  • Ich betreibe XFCE mit eingebauter Grafik, aber ich habe auch eine nVIDIA GTX 650 Ti, die nicht für Grafiken verwendet wird (was im Leerlauf ist, wenn diese Probleme auftreten). Die nVIDIA-Treiberversion ist jetzt 387.26.
  • Wenn der Hang auftritt, zeigt der Monitor weiterhin das letzte Bild an, aber es reagiert nichts. Ctrl+ Alt+ Fnfunktioniert nicht und der Computer reagiert nicht auf Netzwerkverkehr.

Meine maschine

(Ich füge weitere Informationen wie gewünscht hinzu.)

/var/log/syslog vor und nach dem letzten hang:

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 vor und nach dem vorletzten Hang:

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

Die /dev/sddTemperaturprotokolleinträge sind komisch. Sie sehen, ich nicht haben ein sdd. Das heißt, sdaist meine SSD sdbund sdcsind magnetische Festplatten und /dev/sr0ist ein DVD-Player. /dev/sddexistiert nicht einmal als spezielle Datei in /dev.

Zeilen aus anderen Protokollen:

auth.log Zeigt einige chinesische IPs an, die versuchen, als root SSH in meinen Rechner zu schreiben, zB:

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

aber ich denke nicht, dass dies verwandt ist, da dies auch nach dem hang geschieht. Keine anderen Zeilen in anderen Protokollen zwischen der oben genannten datenträgerbezogenen Nachricht und dem Hang.

2
Enthalten die Protokolle etwas Verdächtiges? choroba vor 6 Jahren 1
Überprüfen Sie Ihre Systemprotokolle, bevor Sie - ehrlich gesagt - das tun, was Sie bereits getan haben. Es gibt keinen Grund für ein derartiges Kernel-Downgrade auf einem modernen System. Wie Sie wissen, hat das System nicht funktioniert, während Sie daran arbeiten. Das heißt, Sie wachen morgens auf und sehen, dass etwas nicht in Ordnung war. Vielleicht ein Energiespar- / Schlafproblem? JakeGould vor 6 Jahren 0
@ JakeGould: Ich komme zurück und es hängt, das weiß ich ... Es kann kein Schlafproblem sein, denke ich, da das System immer eingeschaltet ist und in den meisten Nächten nicht hängen bleibt. einpoklum vor 6 Jahren 0
@choroba: Irgendwie, aber ich bin mir nicht sicher, ob es das eigentliche Problem oder nur ein roter Hering ist, siehe Bearbeiten. einpoklum vor 6 Jahren 0
Laufen Sie im Grafik- / X-Windows-Modus oder in der Konsole? Wenn es "aufgehängt" ist, haben Sie immer noch den letzten Bildschirminhalt (und nur keine Reaktion auf Maus oder Tastatur)? Oder ist es ein schwarzer Bildschirm? Können Sie Ctrl-Alt-Fx auf andere Konsolen umschalten und dort Maßnahmen ergreifen? Wie wäre es mit Netzwerkaktivität? Können Sie die Maschine von einer anderen Box aus anpingen? Dave M. vor 6 Jahren 0
@ DaveM .: Ja; ja, letzter Bildschirminhalt; Nein, Sie können nicht zu einer anderen Konsole wechseln, keine Remote-Verbindung herstellen oder einen Ping-Befehl ausführen. einpoklum vor 6 Jahren 0

2 Antworten auf die Frage

3
EvilTorbalan

Es kann sein, dass eines Ihrer Laufwerke getrennt und dann wieder angeschlossen wird, aber als neues Gerät erkannt wird. Nach meiner Erfahrung mit Linux-Servern geschieht dies manchmal, wenn das alte Gerät die Verbindung nicht ordnungsgemäß getrennt hat und der Kernel immer noch seinen Buchstaben enthält und wenn er sich wieder verbindet, wird ihm ein neuer Brief gegeben. Es kann sein, dass eines Ihrer Laufwerke fehlerhaft ist oder die Kabel nicht gesichert sind. Dies hängt wirklich von der Steuerung ab und wie sie mit den Geräten umgeht.

Da Sie sagen, Sie finden die Maschine bereits aufgehängt, und Sie können sie nicht wirklich herumstochern, um zu sehen, was passiert ist. Ich würde vorschlagen, ein kleines Bash-Skript zu schreiben, das ständig die Informationen über alle Laufwerke abruft und in eine Datei schreibt, vorzugsweise in eines der Laufwerke Sie sind sich sicher, sonst wird es möglicherweise nicht geschrieben, wenn Sie es auf das fehlerhafte Laufwerk schreiben. Das Skript könnte etwa so aussehen:

#!/bin/bash    date echo "Starting device data dump"  for drive in sda sdb sdc sdd do echo "Dumping data for drive $" fdisk -l smartctl -a /dev/$ dmesg -T | tail -n50 done echo "Ended device data dump"

Setzen Sie das in cron jede Minute und schreiben Sie die Ausgabe in eine Datei mit

crontab -e

Crontab-Zeile zum Hinzufügen:

* * * * * /usr/local/bin/logcommand.sh >> /var/log/disk-problem.log

Überprüfen Sie nach der Hand, was sich in der Datei befindet. Sie sollten in der Lage sein, die intelligenten Daten von sdd wie Modell, Marke, Seriennummer anzuzeigen und mit Ihren anderen Laufwerken zu vergleichen. Wenn sich einer von ihnen abmeldet, wird es eine Übereinstimmung geben, wenn nicht, können Sie trotzdem Informationen über dieses misterious sdd-Laufwerk erhalten und was es sein könnte.

Prüfen Sie auch, ob Ihre Dmesg in eine Datei in / var / log geschrieben wird. dmesg sollte das Gerät trennen und erkennen lassen.

PS: Da Ihr Rechner aufgehängt ist, wenn Sie ihn finden, ist es wahrscheinlich Ihr Root-Gerät, das Probleme bereitet, da das Basissystem ohne das Gerät nicht funktionieren könnte.

Vielen Dank für die ausführliche Antwort, und ich werde es versuchen. Natürlich muss ich bis zum nächsten Hang auf Ergebnisse warten, und vielleicht gibt es hier sogar einen Heisenberg-Effekt, aber wir werden sehen. einpoklum vor 6 Jahren 0
Schauen Sie sich all Ihre Protokolle an, das ist immer das erste, was Sie als erstes tun können, einige können die Antwort enthalten;) Holen Sie sich das Datum und die Uhrzeit, wann der Hang passiert ist, und durchsuchen Sie ihn in Ihren Protokollen. Was ist vor dem Einfrieren passiert? Letzte Zeilen vor dem Tod :) EvilTorbalan vor 6 Jahren 0
In den Protokollen sind nur einige andere Dinge, die versuchen, meine Box durch SSH'ing als Root-Benutzer zu hacken. einpoklum vor 6 Jahren 0
@einpoklum Ist "root" auf Ihrem System noch aktiviert? So beenden Sie das für immer: Juts erstellen einen neuen Benutzer mit "sudo" -Privilegien, sperren den root-Account und machen weiter mit Ihrem Leben. Ich bezweifle, dass das Hacken durch SSH-Tests verursacht wird, aber es könnte sich lohnen, solche Dinge einfach zu beseitigen, damit Sie mit Sicherheit wissen können, dass das, was in den Protokollen auftaucht, wirklich beachtet werden muss. JakeGould vor 6 Jahren 0
@ JakeGould: Root-Login über SSH war auf meinem System nie aktiviert. Aber ich denke, ich installiere fail2ban und ändere vielleicht meine SSH-Portnummer. Trotzdem bin ich ziemlich überzeugt, dass die Hänge nichts damit zu tun haben. Wir werden sehen, was die Plattenprotokolle sagen. einpoklum vor 6 Jahren 0
@einpoklum Welp, du hast recht ... Es hat nichts mit deinen Hängen zu tun. Aber wenn "root" deaktiviert ist, ist das in Ordnung. Fail2Ban ist auch in Ordnung, aber ich habe gemischte Gefühle. Der Hauptgrund, warum ich es benutze, ist nicht in erster Linie, unerwünschte Zugriffe zu blockieren, sondern ich verwende die gesammelten Daten von blockierenden Angriffen, um Clients zu zeigen: „Hey! Systeme werden ständig geprüft. Denken Sie nicht, dass Sie kein potenzielles Ziel sind. “ JakeGould vor 6 Jahren 0
Der alte Trick "Run a Script" jede Minute ... ist überraschend effektiv für solche Probleme! Vergessen Sie nicht, es auszuschalten, nachdem Sie das Problem erkannt haben. Dave M. vor 6 Jahren 0
Ich sehe / dev / sdd nirgends und zu keiner Zeit mehr. Das minutiöse Disk-Info-Dump-Skript funktioniert, zeigt jedoch kein Strage-Verhalten. Die Protokolle zeigen jedes Mal etwas anderes, aber ich sehe immer eine Zeile wie "Jan 9 16:57:13 my_pc smartd [880]: Gerät: / dev / sda [SAT], Attribut SMART: 190 Airflow_Temperature_Cel von 68 auf geändert 69` einpoklum vor 6 Jahren 0
Die Temperaturänderung sollte innerhalb der Arbeitsgrenzen normal sein. Schließlich verwenden Sie den Frequenzumrichter. EvilTorbalan vor 6 Jahren 0
Also immer noch dieses Problem. Und jetzt - ich bekomme nicht einmal die temperaturbezogenen Meldungen im Protokoll. einpoklum vor 6 Jahren 0
1
Mike

Ich weiß nicht, ob das hilft, aber ich habe eine ähnliche Situation. Das System ist ein Intel NUC mit Linux Mint 18.3 (XFCE) mit 8 GB RAM und einer M2-SSD, die den OPs sehr ähnlich ist.

Meine Probleme zeigen sich nur beim Ausführen von Thunderbird. Ich leite alle meine Thunderbird-Daten an einen anderen Linux Mint-Computer, den ich als Server verwende. Kleine Thunderbird-Konten funktionieren (nur), aber die größeren führen dazu, dass das System instabil wird und Thunderbird nicht wirklich läuft.

Linux Mint 18.3 (XFCE) wird mit Linux Kernel 4.10.0-38 geliefert und funktioniert auf meinem System gut - Thunderbird funktioniert genauso wie auf anderen Systemen. Wenn ich jedoch den Linux-Kernel unter Verwendung des integrierten Mint-Aktualisierungspakets auf 4.10.0-42 aktualisiere, verursacht Thunderbird die oben genannten Probleme.

Ich muss betonen, dass dieses Problem (mit dem neueren Kernel - 4.10.0-42) nur auf meinem NUC-Computer auftritt - andere Systeme funktionieren gut mit dem aktualisierten Kernel.

Meine Übergangslösung besteht darin, beim Kernel 4.10.0-38 zu bleiben und alle Upgrades vor dem Einsatz vollständig zu testen.

+1 für Mühe. Ich mache mir allerdings ein bisschen Sorgen, ob ich frühere Kernel verwenden könnte. einpoklum vor 6 Jahren 0
Das scheint nicht zu funktionieren. Ich habe versucht, meine Kernel-Version hier und dort zu wechseln, und nicht viel Wirkung. Dieses Problem auch mit 4.13.x erhalten einpoklum vor 6 Jahren 0

Verwandte Probleme