Linux

Eine 20-GB-Logdatei mit einer Bash-Schleife zu verarbeiten, die Zeilen in einem Array sammelt, ist einer der zuverlässigsten Wege, einen Server ins Swapping zu treiben. awk ist von Grund auf als Streaming-Werkzeug gebaut, verarbeitet jede Zeile einzeln und hält den Speicherverbrauch unabhängig von der Dateigröße nahezu konstant.

inotify ist eine Kernel-Schnittstelle, die Bash-Skripte sofort benachrichtigt, sobald sich eine Datei oder ein Verzeichnis ändert, statt in einer Schleife immer wieder nachzuschauen. Mit dem Kommandozeilenwerkzeug inotifywait aus dem Paket inotify-tools lassen sich Deployment-Trigger, Config-Reloads und Log-Watcher bauen, die auf echte Ereignisse reagieren statt auf eine feste Zeitspanne.

Nicht jedes Team hat Grafana oder ein ELK-Stack im Zugriff, wenn es schnell wissen muss, wie viele Fehler ein Dienst gerade produziert. Ein Bash-Terminal-Dashboard aus watch, tput und ANSI-Farbcodes zeigt Fehlerquoten, Request-Raten und Log-Level live an, direkt in der SSH-Session, ohne Browser und ohne zusätzliche Infrastruktur.

Ein Bash-Skript, das als Daemon oder langlaufender Prozess läuft, muss auf SIGINT, SIGTERM und SIGHUP reagieren können, ohne verwaiste Sperrdateien oder halb geschriebene Ausgaben zu hinterlassen. Ein einziger trap-Aufruf kann denselben Handler für mehrere Signale registrieren, doch wer im Handler wissen will, welches Signal konkret ausgelöst hat, und Doppelläufe beim Zusammenspiel mit einem EXIT-Trap vermeiden will, braucht ein paar zusätzliche Kniffe.

Jeder Linux-Prozess besitzt eine eindeutige PID und verweist über seine PPID auf seinen Elternprozess, wodurch ein nachvollziehbarer Baum aus Eltern- und Kind-Prozessen entsteht. Dieser Artikel zeigt, wie man diesen Baum mit ps und pstree liest, warum verwaiste Prozesse zu PID 1 wandern und wie man in der Praxis einen hängenden PHP-FPM-Worker gezielt aufspürt und beendet.

Wenn top nur zeigt, dass die CPU beschäftigt ist, aber nicht womit, hilft klassisches Monitoring nicht weiter. Kernel-Tracing mit ftrace und perf macht sichtbar, welche Funktion im Kernel wie lange läuft, welcher Syscall blockiert und wo genau die Zeit in einem scheinbar einfachen Request verschwindet.

Die meisten erfolgreichen Angriffe auf Linux-Server treffen auf offene SSH-Passwort-Logins, fehlende Firewall-Regeln und veraltete Pakete, nicht auf ausgeklügelte Zero-Day-Exploits. Dieser Artikel zeigt eine praxistaugliche Härtungs-Baseline, die mit wenig Aufwand den größten Teil der Angriffsfläche schließt, ohne den Betrieb unnötig zu erschweren.

Ein Zombie-Prozess hat sich bereits beendet, doch sein Elternprozess hat den Exit-Status nie abgeholt und blockiert damit einen Eintrag in der Prozesstabelle. Dieser Leitfaden erklärt den Unterschied zwischen Zombies und verwaisten Prozessen, zeigt, warum kill -9 wirkungslos bleibt, und liefert konkrete Befehle, um den verantwortlichen Elternprozess zu finden und das Problem im Code dauerhaft zu beheben.

GRUB2 ist auf den meisten Linux Servern die letzte Instanz zwischen Firmware und Kernel und wird trotzdem oft nur einmal bei der Installation berührt. Wer Kernel Parameter dauerhaft setzen, ein Multi Kernel Setup sauber pflegen oder nach einem missglückten Update wieder booten muss, braucht ein belastbares Verständnis von /etc/default/grub, grub2-mkconfig und der Rescue Shell.

Eine belastbare PCI-DSS Härtung setzt konkrete Linux Konfiguration voraus, nicht nur Prozessdokumentation. Wer versteht, welche Anforderungen des Standards direkt am Server ansetzen, kann Firewall-Segmentierung, Zugriffskontrolle, Logging und Datei-Integrität so umsetzen, dass sie einem Qualified Security Assessor standhalten.