GNU/Linux Allgemeine Anleitung zur Fehlerbehebung für Anfänger
In diesem Leitfaden ist es unser Ziel, mehr über die Werkzeuge und die Umgebung zu erfahren, die von einem typischen GNU/Linux-System bereitgestellt werden, um auch auf einem unbekannten Rechner mit der Fehlerbehebung beginnen zu können.
- So überprüfen Sie den Speicherplatz
- So überprüfen Sie die Speichergröße
- So überprüfen Sie die Systemauslastung
- So finden und beenden Sie Systemprozesse
- So finden Sie in den Benutzerprotokollen relevante Informationen zur Systemfehlerbehebung
GNU/Linux Allgemeine Anleitung zur Fehlerbehebung für Anfänger
Verwendete Softwareanforderungen und Konventionen
Einleitung
Obwohl GNU/Linux für seine Stabilität und Robustheit bekannt ist, gibt es Fälle, in denen etwas schief gehen kann. Die Ursache des Problems kann sowohl intern als auch extern sein. Beispielsweise kann ein fehlerhafter Prozess auf dem System ausgeführt werden, der Ressourcen verbraucht, oder eine alte Festplatte ist defekt, was zu gemeldeten E/A-Fehlern führt.
In jedem Fall müssen wir wissen, wo wir suchen und was zu tun ist, um Informationen über die Situation zu erhalten, und dieser Leitfaden versucht, genau das zu vermitteln – eine allgemeine Möglichkeit, sich vorzustellen, was schief gelaufen ist. Die Lösung eines Problems beginnt damit, das Problem zu kennen, die Details zu finden, die Ursache zu finden und es zu lösen. Wie bei jeder Aufgabe bietet GNU/Linux unzählige Werkzeuge, um den Fortschritt zu unterstützen, dies ist auch bei der Fehlerbehebung der Fall. Die folgenden Tipps und Methoden sind nur einige der gängigen, die auf vielen Distributionen und Versionen verwendet werden können.
Symptome
Nehmen wir an, wir haben einen schönen Laptop, an dem wir arbeiten. Es läuft das neueste Ubuntu, CentOS oder Red Hat Linux darauf, mit Updates, die immer vorhanden sind, um alles auf dem neuesten Stand zu halten. Der Laptop ist für den täglichen Gebrauch bestimmt: Wir bearbeiten E-Mails, chatten, surfen im Internet, erstellen vielleicht einige Tabellenkalkulationen usw. Es ist nichts Besonderes installiert, weder eine Office Suite, noch ein Browser, ein E-Mail-Client und so weiter. Von einem Tag auf den anderen wird die Maschine plötzlich extrem langsam. Wir arbeiten bereits etwa eine Stunde daran, so dass es nach dem Booten kein Problem mehr ist. Was passiert...?
Überprüfen von Systemressourcen
GNU/Linux wird nicht ohne Grund langsam. Und wird uns höchstwahrscheinlich sagen, wo es weh tut, solange es in der Lage ist, zu antworten. Wie bei jedem Programm, das auf einem Computer ausgeführt wird, verwendet das Betriebssystem Systemressourcen, und bei solchen, die dick ausgeführt werden, müssen die Vorgänge warten, bis genügend davon vorhanden sind, um fortzufahren. Dies führt in der Tat dazu, dass die Antworten immer langsamer werden, so dass es bei Problemen immer sinnvoll ist, den Zustand der Systemressourcen zu überprüfen. Im Allgemeinen bestehen unsere (lokalen) Systemressourcen aus Festplatte, Speicher und CPU. Schauen wir uns alle an.
Speicherplatz
Wenn auf dem laufenden Betriebssystem nicht genügend Speicherplatz vorhanden ist, ist das eine schlechte Nachricht. Da laufende Dienste ihre Protokolldateien nicht schreiben können, stürzen sie meistens ab, wenn sie ausgeführt werden, oder werden nicht gestartet, wenn die Festplatten bereits voll sind. Abgesehen von Logfiles müssen auch Sockets und PID-Dateien (Process IDentifier) auf die Festplatte geschrieben werden, und obwohl diese klein sind, können sie nicht erstellt werden, wenn absolut kein Speicherplatz mehr vorhanden ist.
Um den verfügbaren Speicherplatz zu überprüfen, können wir df im Terminal verwenden und das Argument -h hinzufügen, um die Ergebnisse auf Megabyte und Gigabyte aufgerundet zu sehen. Für uns wären die Einträge, die uns interessieren, Volumina, die einen Use% von 100% haben. Das würde bedeuten, dass das betreffende Volumen voll ist. Die folgende Beispielausgabe zeigt, dass wir in Bezug auf den Speicherplatz in Ordnung sind:
df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.8G 0 1.8G 0% /dev
tmpfs 1.8G 0 1.8G 0% /dev/shm
tmpfs 1.8G 1.3M 1.8G 1% /run
/dev/mapper/lv-root 49G 11G 36G 24% /
tmpfs 1.8G 0 1.8G 0% /tmp
/dev/sda2 976M 261M 649M 29% /boot
/dev/mapper/lv-home 173G 18G 147G 11% /home
tmpfs 361M 4.0K 361M 1% /run/user/1000Wir haben also Platz auf Festplatte(n). Beachten Sie, dass in unserem Fall des langsamen Laptops die Erschöpfung des Speicherplatzes wahrscheinlich nicht die Ursache ist. Wenn die Festplatten voll sind, stürzen Programme ab oder starten überhaupt nicht. Im Extremfall schlägt auch die Anmeldung nach dem Booten fehl.
Gedächtnis
Speicher ist auch eine lebenswichtige Ressource, und wenn wir ihn knapp haben, muss das Betriebssystem möglicherweise derzeit ungenutzte Teile davon auf die Festplatte temporär schreiben (auch "Swap Out" genannt), um den freigewordenen Speicher dem nächsten Prozess zur Verfügung zu stellen, und ihn dann wieder zurücklesen, wenn der Prozess, der den ausgelagerten Inhalt besitzt, ihn wieder benötigt. Diese ganze Methode wird als Swapping bezeichnet und wird das System in der Tat verlangsamen, da das Schreiben und Lesen von und zu den Festplatten viel langsamer ist als das Arbeiten im RAM.
Um die Speicherauslastung zu überprüfen, haben wir den praktischen kostenlosen Befehl, den wir mit Argumenten anhängen können, um die Ergebnisse in Megabyte (-m) oder Gigabyte (-g) anzuzeigen:
free -m
total used free shared buff/cache available
Mem: 7886 3509 1547 1231 2829 2852
Swap: 8015 0 8015Im obigen Beispiel haben wir 8 GB Arbeitsspeicher, 1,5 GB davon frei und etwa 3 GB in Caches. Der Befehl free gibt auch den Status des Swaps an: In diesem Fall ist er vollkommen leer, was bedeutet, dass das Betriebssystem seit dem Start keine Speicherinhalte auf die Festplatte schreiben musste, auch nicht bei Spitzenlasten. Das bedeutet normalerweise, dass wir mehr Speicher haben, den wir tatsächlich nutzen. Was das Gedächtnis angeht, sind wir also mehr als gut, wir haben viel davon.
Systemlast
Da die Prozessoren die eigentlichen Berechnungen durchführen, kann die Prozessorzeit für die Berechnung erneut zu einer Verlangsamung des Systems führen. Erforderliche Berechnungen müssen warten, bis ein Prozessor die freie Zeit hat, sie zu berechnen. Der einfachste Weg, die Auslastung unserer Prozessoren zu sehen, ist der uptime-Befehl:
uptime
12:18:24 up 4:19, 8 users, load average: 4,33, 2,28, 1,37Die drei Zahlen nach dem Lastdurchschnitt bedeuten den Durchschnitt der letzten 1, 5 und 15 Minuten. In diesem Beispiel hat die Maschine 4 CPU-Kerne, so dass wir versuchen, mehr als unsere tatsächliche Kapazität zu nutzen. Beachten Sie auch, dass die historischen Werte zeigen, dass die Last in den letzten Minuten deutlich ansteigt. Vielleicht haben wir den Schuldigen gefunden?
Top-Consumer-Prozesse
Sehen wir uns das Gesamtbild des CPU- und Speicherverbrauchs an, wobei die wichtigsten Prozesse, die diese Ressourcen verwenden, vorhanden sind. Wir können den Top-Befehl ausführen, um die Systemlast in (nahezu) Echtzeit zu sehen:
Überprüfung der wichtigsten Verbraucherprozesse.
Die erste Zeile oben ist identisch mit der Ausgabe der Betriebszeit, als nächstes sehen wir die Anzahl der ausgeführten, schlafenden Aufgaben usw. Notieren Sie die Anzahl der Zombie-Prozesse (die nicht funktionieren; In diesem Fall ist es 0, aber wenn es einige Prozesse im Zombie-Zustand geben würde, sollten sie untersucht werden. Die nächste Zeile zeigt die Auslastung der CPUs in Prozent und die kumulierten Prozentsätze genau dessen, womit die Prozessoren beschäftigt sind. Hier können wir sehen, dass die Prozessoren damit beschäftigt sind, Userspace-Programme zu bedienen.
Es folgen zwei Zeilen, die man aus der freien Ausgabe kennen kann, die Speicherauslastung des Systems. Darunter befinden sich die Top-Prozesse, sortiert nach CPU-Auslastung. Jetzt können wir sehen, was unsere Prozessoren frisst, in unserem Fall ist es Firefox.
Prozesse prüfen
Woher weiß ich das, da der Prozess mit dem höchsten Verbrauch als "Web Content" in meiner Top-Ausgabe angezeigt wird? Indem Sie ps verwenden, um die Prozesstabelle abzufragen, indem Sie die PID verwenden, die neben dem obersten Prozess angezeigt wird, der in diesem Fall 5785 ist:
ps -ef| grep 5785 | grep -v "grep"
sandmann 5785 2528 19 18:18 tty2 00:00:54 /usr/lib/firefox/firefox -contentproc -childID 13 -isForBrowser -prefsLen 9825 -prefMapSize 226230 -parentBuildID 20200720193547 -appdir /usr/lib/firefox/browser 2528 true tabMit diesem Schritt haben wir die Ursache unserer Situation gefunden. Firefox frisst unsere CPU-Zeit bis zu dem Punkt, an dem unser System anfängt, langsamer auf unsere Aktionen zu reagieren. Das ist nicht unbedingt die Schuld des Browsers,
denn Firefox ist darauf ausgelegt, Seiten aus dem World Wide Web anzuzeigen: Um ein CPU-Problem zu Demonstrationszwecken zu erzeugen, habe ich nur ein paar Dutzend Instanzen einer Stresstest-Seite in verschiedenen Tabs des Browsers geöffnet, bis zu dem Punkt, an dem die CPU-Knappheit auftaucht. Ich muss also nicht meinem Browser, sondern mir selbst die Schuld dafür geben, dass ich ressourcenhungrige Seiten öffne und sie parallel laufen lasse. Durch das Schließen einiger wird meine CPU
-Auslastung wieder normalisiert.
Prozesse zerstören
Das Problem und die Lösung wurden oben aufgedeckt, aber was ist, wenn ich nicht auf den Browser zugreifen kann, um einige Registerkarten zu schließen? Nehmen wir an, meine grafische Sitzung ist gesperrt und ich kann mich nicht wieder anmelden, oder ein general
-Prozess, der verrückt geworden ist, hat nicht einmal eine Schnittstelle, an der wir sein Verhalten ändern können? In diesem Fall können wir das Herunterfahren des Prozesses durch das Betriebssystem veranlassen. Wir kennen bereits die PID des
betrügerischen Prozesses, den wir mit ps erhalten haben, und wir können den Befehl kill verwenden, um ihn zu schließen:
kill 5785Sich gut verhaltende Prozesse werden beendet, andere vielleicht nicht. Wenn dies der Fall ist, erzwingt das Hinzufügen des Flags -9 die Beendigung des Prozesses:
kill -9 5785Beachten Sie jedoch, dass dies zu Datenverlust führen kann, da der Prozess keine Zeit hat, geöffnete Dateien zu schließen oder das Schreiben der Ergebnisse auf die Festplatte überhaupt zu beenden. Aber im Falle einer wiederholbaren Aufgabe kann die Systemstabilität Vorrang vor dem Verlust einiger unserer Ergebnisse haben.
Verwandte Informationen finden
Die Interaktion mit Prozessen mit einer Art Schnittstelle ist nicht immer der Fall, und viele Anwendungen haben nur grundlegende Befehle, die ihr Verhalten steuern – nämlich Starten, Stoppen, Neuladen und dergleichen, da ihre internen Abläufe durch ihre Konfiguration bereitgestellt werden. Das obige Beispiel war eher ein Desktop-Beispiel, sehen wir uns ein serverseitiges Beispiel an, bei dem wir ein Problem mit einem Webserver haben.
Angenommen, wir haben einen Webserver, der der Welt Inhalte zur Verfügung stellt. Es ist beliebt, daher ist es keine gute Nachricht, wenn wir einen Anruf erhalten, dass unser Service nicht verfügbar ist. Wir können die Webseite nur in einem Browser überprüfen, um die Fehlermeldung "Verbindung nicht möglich" zu erhalten. Sehen wir uns die Maschine an, auf der der Webserver läuft!
Überprüfen von Logfiles
Unser Rechner, auf dem der Webserver gehostet wird, ist eine Fedora-Box. Dies ist aufgrund der Dateisystempfade, denen wir folgen müssen, wichtig. Fedora und alle anderen Red Hat-Varianten speichern die Protokolldateien des Apache Webservers unter dem Pfad /var/log/httpd. Hier können wir die error_log mit der Ansicht überprüfen, finden aber keine zugehörigen Informationen darüber, was das Problem sein könnte. Auch die Überprüfung der Zugriffsprotokolle zeigt auf den ersten Blick keine Probleme, aber wenn wir zweimal überlegen, erhalten wir einen Hinweis: Auf einem Webserver mit ausreichend Traffic sollten die letzten Einträge des Zugriffsprotokolls sehr aktuell sein, aber der letzte Eintrag ist bereits eine Stunde alt. Wir wissen aus Erfahrung, dass die Website jede Minute Besucher bekommt.
Systemd
Unsere Fedora-Installation verwendet systemd als Init-System. Lassen Sie uns einige Informationen über den Webserver abfragen:
systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/httpd.service.d
└─php-fpm.conf
Active: failed (Result: signal) since Sun 2020-08-02 19:03:21 CEST; 3min 5s ago
Docs: man:httpd.service(8)
Process: 29457 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=killed, signal=KILL)
Main PID: 29457 (code=killed, signal=KILL)
Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec: 0 B/sec"
CPU: 74ms
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29665 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29666 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29667 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29668 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29669 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29670 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29671 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29672 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Killing process 29673 (n/a) with signal SIGKILL.
aug 02 19:03:21 mywebserver1.foobar systemd[1]: httpd.service: Failed with result 'signal'.Das obige Beispiel ist wieder ein einfaches, der httpd-Hauptprozess ist ausgefallen, weil er ein KILL-Signal empfangen hat. Möglicherweise gibt es einen anderen Systemadministrator, der das Privileg hat, dies zu tun, so dass wir überprüfen können, wer
angemeldet ist (oder zum Zeitpunkt des gewaltsamen Herunterfahrens des Webservers angemeldet war), und sie/ihn nach dem Problem fragen kann (ein ausgeklügelter Servicestopp wäre weniger brutal gewesen, also muss es einen Grund für dieses Ereignis geben
). Wenn wir die einzigen Administratoren auf dem Server sind, können wir überprüfen, woher dieses Signal stammt – möglicherweise haben wir ein Problem mit einer Sicherheitsverletzung oder das Betriebssystem hat das Kill-Signal gesendet. In beiden Fällen können wir die Protokolldateien des Servers
verwenden, da SSH-Anmeldungen in den Sicherheitsprotokollen (/var/log/secure im Fall von Fedora) protokolliert werden, und es gibt auch Überwachungseinträge, die im Hauptprotokoll zu finden sind (in diesem Fall
/var/log/messages). Es gibt einen Eintrag, der uns erzählt, was in letzterem passiert ist:
Aug 2 19:03:21 mywebserver1.foobar audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=httpd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'Schlussfolgerung
Zu Demonstrationszwecken habe ich in diesem Beispiel den Hauptprozess meines eigenen Labor-Webservers beendet. Bei einem serverbezogenen Problem besteht die beste Hilfe, die wir schnell erhalten können, darin, die Protokolldateien zu überprüfen und das System nach laufenden Prozessen (oder deren Abwesenheit) abzufragen und ihren gemeldeten Status zu überprüfen, um dem Problem näher zu kommen. Um dies effektiv zu tun, müssen wir die Dienste kennen, die wir ausführen: Wo schreiben sie ihre Protokolldateien, wie
können wir Informationen über ihren Status erhalten, und zu wissen, was zu normalen Betriebszeiten protokolliert wird, hilft auch sehr bei der Identifizierung eines Problems – vielleicht sogar bevor der Dienst selbst Probleme hat.
Es gibt viele Tools, die uns helfen, die meisten dieser Dinge zu automatisieren, wie z. B. ein Überwachungssubsystem und Log><-Aggregationslösungen, aber diese beginnen alle mit uns, den Administratoren, die wissen, wie die Dienste, die wir ausführen, funktionieren, wo und was überprüft werden muss, um zu wissen, ob sie fehlerfrei sind. Die oben gezeigten einfachen Tools sind in jeder Distribution zugänglich, und mit ihrer Hilfe können wir helfen, Probleme mit Systemen zu lösen, mit denen wir nicht einmal vertraut sind
. Das ist eine fortgeschrittene Stufe der Fehlerbehebung, aber die hier gezeigten Tools und ihre Verwendung sind einige der Bausteine, die jeder verwenden kann, um seine Fähigkeiten zur Fehlerbehebung unter GNU/Linux aufzubauen.