„Es tut uns leid, aber etwas ist schief gelaufen.“
„Verbindungsfehler.“
„Kein Gerät gefunden.“
„Unbekannter Fehler.“
GUI-Anwendungen sind eine tolle Sache. Nein, ehrlich. Sie helfen Leuten, die sinnvolle Dinge für die Gesellschaft tun, mit Computern umzugehen. Du kannst STRG+S drücken um zu speichern oder Du klickst auf dieses kleine Symbol einer Diskette … das war was, was Mama und Papa benutzt haben als sie klein waren – bevor es USB-Sticks gab.
Das Problem ist nur, dass es nur eine sehr begrenzte Anzahl an Konzepten gibt, die sich visuell in einer GUI darstellen lassen bevor sie zu komplex wird und mehr Schaden anrichtet als dass sie hilft. Das hat zur Folge, dass Programme ab einem gewissen Punkt aufgeben und mit den Schultern zucken und man „die Motorhaube öffnen“ muss, um herauszufinden, warum das Internet nicht geht oder die Bluetoothkopfhörer nicht gefunden werden oder warum das System plötzlich so langsam ist.
Nein, ehrlich … was geht hier vor?
Wenn ich wissen will was eigentlich gerade so auf meinem System läuft ist der klassische Befehl
ps -aux --forest
… wobei das --forest eine hübsche Hierarchie darüber mitgibt, welche Prozesse eigentlich Kinder von welchen Prozessen sind.
top gibt eine sortierte live-Übersicht der laufenden Prozesse, nicht ungleich des Windows Task Managers. Wer es bunt mag, kommt mit htop auf seine Kosten. Ein Programm, das so bunt und beweglich ist, dass es sehr gerne auf Filmsets hergenommen wird.
Das Netzwerkäquivalent ist iftop -i wlan0 (das wlan0 durch das gewünschte Interface ersetzen.) Mit wem reden wir eigentlich gerade? Wer redet mit uns? Und mit welcher Geschwindigkeit?
Was blockiert gerade diesen Port?
Ein absoluter Klassiker bei Entwicklern. Es laufen noch acht alte Bastelprojekte auf dem Laptop und jetzt fährt die Dockerumgebung nicht rauf, weil der Port schon in Benutzung ist.
Wenn euer erster Impuls netstat ist, seid euch bitte bewusst, dass das net-tools-Paket schon seit mehr als zehn Jahren deprecated ist. Stattdessen benutzt bitte ss.
ss -ltnp | grep "31337"
Der Output hier ist allerdings nicht sonderlich hilfreich. Irgendetwas lauscht auf diesem Port. Na gut. Kriegen wir nicht irgendwie die PID raus, damit wir den zugehörigen Prozess grauenvoll ermor… liebevoll beenden können?
sudo lsof -i :31337
Da haben wir ihn ja. Und sollte hier einfach nur „docker-pr“ stehen, finden wir unseren Schuldigen ganz leicht mit
docker ps | grep "31337"
Wenn ich einfach nur wissen möchte welcher Prozess gerade Netzwerkverbindungen aufmacht, gibt mir sudo lsof -i eine nette Übersicht.
umount – target is busy
Ich will doch einfach nur meinen USB-Stick wiederhaben! Soll ich ihn jetzt gewaltsam rausrupfen?
Tief durchatmen.
lsof | grep /media/ort_wo_usb_stick_gemounted_ist
wenn hier ein Prozess gelistet ist, diesen einfach liebevoll beenden.
Dann wieder
umount /media/ort_wo_usb_stick_gemounted_ist
und wenn das nicht hilft
umount -l /media/ort_wo_usb_stick_gemounted_ist
um das Unmounten zu erzwingen.
Ey Mann, wo is mein USB-Stick?
Gerade Deinen USB-Stick eingesteckt und nichts ist passiert? Zeit für ein wenig klassisches Debugging.
sudo dmesg | tail
gibt die neuesten Nachrichten vom Kernel aus. Wenn hier nichts auftaucht, ist es wahrscheinlich ein Hardwareproblem.
lsusb gibt die erkannten USB-Geräte aus. Und lsblk gibt alle Datenträger aus, die das System gefunden hat. Taucht er dort auf kann man versuchen ihn zu mounten.
sudo mkdir /media/tollermountpoint sudo mount /dev/sdb1 /media/tollermountpoint
Logischerweise /dev/sdb1 vorher durch das richtige Device ersetzen.
Ein anderes gotcha können hier nicht-installierte Treiber sein. Zum Beispiel für ntfs.
Und mein allerliebstes Gotcha: Gerade ein Systemupdate gemacht? Neuer Kernel? Herzlichen Glückwunsch, alle LKMs wurden jetzt rausgekegelt. Die einfachste Methode das zu reparieren ist ein Reboot.
Warum ist das System so langsam?
Ich hatte ps ja schon erwähnt. Es speichert leider keine historischen Daten, aber es kann uns die akkumulierte CPU-Zeit von Prozessen geben seid sie gestartet sind.
ps -eo pid,comm,pcpu,etime --sort=-pcpu | head -n 20
oder wie viel Speicher sie jetzt gerade im Moment beanspruchen:
ps -eo pid,comm,pmem,rsz,vsz --sort=-pmem | head -n 20
Im sysstat-Paket gibt es iostat
watch -n1 iostat
was uns einen schnellen Überblick darüber gibt, welche Festplatten gerade heftig beansprucht werden.
Um Prozesse und ihren aktuellen Netzwerkbandbreitenverbrauch anzuschauen, mag ich
sudo nethogs
Hat man nun den Resourcenfresser gefunden (beispielsweise mit der PID „12345“), kann man ihm mit kill 12345 ein freundliches Signal und mit kill -9 12345 ein weniger freundliches Signal schicken, dass es jetzt an der Zeit ist, aufzuhören. Das ist noch eins unfreundlicher als das „Beenden erzwingen“ unter Windows.
Wo bin ich hier?
Ich hatte ja schon in längeren philosophischen Shell-Weisheiten erzählt, dass die Shell transparent ist und es ist super cool und spacig und total Cyberpunk und Science-Fiction, aber ab irgendeinem Punkt ist es wie an einem unbekannten Flughafen in einem Flugzeug aufzuwachen, mit keinem benutzbaren Handynetz und die Frage zu stellen: Wo verdammt bin ich hier eigentlich? Auf was habe ich mich gerade per ssh verbunden und warum funktionieren nur die Hälfte der Befehle?
uname -a
funktioniert auf Linux und Mac und gibt den ersten Hinweis, wo wir hier eigentlich sind.
Unter Linux geht es weiter mit
cat /etc/*release
und schon sollten wir Distro und Version kennen und somit einige nützliche Informationen haben.
Unter Mac hilft sw_vers und unter Windows entweder Get-ComputerInfo in der Powershell oder systeminfo in der cmd (der „Eingabeaufforderung“, immer noch das objektiv deutscheste Synonym für Kommandozeile).
Natürlich kann man leicht noch mehr Informationen aus dem System rausholen:
ip addr # Netzwerkadapter mit IP-Adressen du # Gemountete Datenträger und verfügbarer Platz free # Arbeitsspeicher lscpu # Prozessoren lsblk # Datenträger (auch nicht gemountete) lspci # siehe unten sudo dmidecode # siehe unten
Wenn das die eigene Neugier immer noch nicht gestillt hat, geht es weiter mit den Security-Audit-Tools eures Vertrauens. Ggf. müsst ihr sie dazu natürlich aufs System laden. (Themen für einen anderen Blogartikel.)
Ein Ohr auf der Festplatte
Als die Computer noch lauter waren – in der Zeit von IDE-Festplatten – konnte ich schwören, dass ich an den Klicks erkennen konnte wenn Sachen im System falsch liefen. Jugendlicher Hybris und Maschinengeister mal zur Seite, manchmal will man Hardware debuggen.
lspci -vv | less
zeigt alles, was am aktuellen Gerät angeschlossen ist. Ich würde lügen wenn ich sage, dass ich den Output in seiner Gänze verstehe – aber wenn man alle Infos über z. B. das eigene Ethernet-Chipset sucht, dann sind sie hier.
lscpu gibt alle relevanten Infos zu euren CPUs aus. Virtualisierungssupport? Spectre v1 und Spectre v2 Mitigationen? Hier im Output findet ihr es.
lscpu -e gibt eine hübsche Tabelle aus, welche Cores gerade online sind und wie hoch sie getaktet sind.
Wer sich lm-sensors installiert und mit
sudo sensors-detect
konfiguriert, kann mit sensors sämtliche Temperatursensoren im Gerät auslesen. Ist einer der Lüfter kaputt? Wir die Grafikkarte zu heiß? Hier im Output könnt ihr es nachlesen.
Für alle Informationen die euch das BIOS liefern kann gibt es sudo dmidecode. Hier sollte so ziemlich alles aufgelistet sein; inklusive aller Anschlüsse, die das Gerät hat.
OK, dann legen wir mal unser Ohr auf die Festplatte.
smartctl -a /dev/sda
Falls das nicht geht: smartmontools installieren. Die meisten modernen unterstützen SMART und geben eine Fülle an Informationen aus.
Nicht länger im Dunkeln tappen
Computer sind komplexe Systeme, die auf viele künstlerisch wertvolle Arten und Weisen kaputt gehen können. Es ist unmöglich, alle diese Arten zu erfassen. Aber je mehr Wege wir haben um uns Informationen zu beschaffen, desto mehr Erfolg werden wir haben, Dinge zu debuggen.
Ich bin Vater eines Vierjährigen und einer der positivsten Einflüsse auf mein Kind ist Laura Kampf. Laura ist bei der Sendung mit der Maus dabei und baut aus „Abfall“ Erfindungen: Eine wasserspritzende Fotokamera, einen leuchtenden Regenschirm, eine Steinflitschmaschine und viele andere Sachen. (Alles in der ARD Mediathek, definitive Anschau-Empfehlung.)
Das schöne daran wie Laura das macht: Sie zeigt den kompletten Prozess, inklusive der Fehler und der falschen Ansätze. Sie hat mein Kind auf jeden Fall motiviert, eine Reihe von Steinflitschmaschinen aus Lego zu bauen.
Was hat das ganze jetzt mit der Shell zu tun? Warum erzähle ich davon? Nun … wenn wir moderne Konsumenten ein Problem haben, suchen wir oft ein Produkt oder einen Experten, um es zu lösen. Die wenigsten von uns haben die Zeit und die Muße, wie Laura in die Werkstatt zu gehen und die Bohrmaschine anzusetzen.
Doch genau das sollten wir.
Es braucht nämlich gar nicht so viel Zeit. Es braucht gar nicht so viel Fähigkeit oder teure Materialien. Anders als „echte“ Softwareentwicklung – in der wir ein Produkt entwickeln, dass auf vielen Plattformen, für viele Leute und in vielen Kontexten funktionieren muss („Was ist, wenn der Dateiname mit einem Strich anfängt?“) – müssen unsere Skripte zumindest erstmal nur für uns funktionieren.
Wir können unsere Einstellungen hardcoden. Wir können einen festen Ablauf machen der elf Möglichkeiten bruteforcet, obwohl nur eine zutreffen kann. Wen kümmert es, wenn das Skript zwei Minuten zum Ausführen braucht? Wir packen es einfach in einen Cron-Job. Wir können Skripte schreiben, die sich wie der hinterletzte Schrott anfühlen … Ingenieure sagen dazu „Prototyp“. Wenn es einen Mehrwert bringt, dann ist es kein Müll. Wenn wir es deswegen schnell schreiben konnten, dann sind wir sowohl effektiv als auch effizient gewesen.
Skripte wie diese sind eine Suche. Wir lernen unsere Arbeitsprobleme besser kennen. Wir lernen uns selbst besser kennen. Die Skripte die etwas zu unserer Arbeit beitragen, bleiben. Ein Skript, das lange genug lebt um refactort zu werden, ist eine Erfolgsgeschichte.
Also, nur Mut! Einfach mal basteln. Einfach mal schauen. Einfach mal eins besser machen. Das Leben belohnt Menschen die auch mal mit Duct Tape arbeiten.
Schreibe einen Kommentar