8.4 Linux-Server – Dienste, Prozesse, Protokolle, Ressourcen und Speicher

1. Ziel dieser Seite

Diese Seite beschreibt die strukturierte Fehleranalyse auf Linux-Servern.

Typische Störungen betreffen:

Das Ziel ist nicht, einen Dienst möglichst schnell neu zu starten. Zuerst werden Fehlerzustand, Ursache, Auswirkungen und Rückweg dokumentiert.

2. Diagnosegrundsatz

Symptom erfassen
        ↓
Umfang bestimmen
        ↓
Systemzustand und Zeitpunkt prüfen
        ↓
Dienst, Prozess und Port untersuchen
        ↓
Protokolle auswerten
        ↓
Abhängigkeiten prüfen
        ↓
Konfiguration und Berechtigungen prüfen
        ↓
Ressourcen und Storage prüfen
        ↓
Ursache nachweisen
        ↓
Eine kontrollierte Maßnahme durchführen
        ↓
Funktion und Nebenwirkungen kontrollieren

Ein erfolgreicher Prozessstart beweist noch keine funktionierende Anwendung. Ebenso beweist ein offener Port nicht, dass die Anwendung korrekte Antworten liefert.

3. Fehlerbild exakt erfassen

Zu dokumentieren sind:

Wichtige Abgrenzungsfragen:

4. System identifizieren

Hostname:

hostnamectl

Kurzer Hostname:

hostname

Betriebssysteminformationen:

cat /etc/os-release

Kernelversion und Architektur:

uname -a

Nur Kernelversion:

uname -r

Architektur:

uname -m

Systemlaufzeit und Last:

uptime

Letzter Systemstart:

who -b

Aktuelle Zeit und Zeitzone:

timedatectl

Diese Informationen sind wichtig, weil Befehle, Dateipfade, Paketmanager, Sicherheitsmodule und Protokollierung je nach Distribution und Version unterschiedlich sein können.

5. Letzte Änderungen bestimmen

Mögliche Ursachen kurz vor Beginn einer Störung:

Anmeldehistorie:

last

Fehlgeschlagene Anmeldungen, sofern unterstützt und berechtigt:

lastb

Letzte Neustarts:

last reboot

Zeitstempel einer Datei:

stat /etc/example/application.conf

RPM-basierte Systeme:

dnf history

Debian- und Ubuntu-Systeme:

grep -E ' install | upgrade | remove ' /var/log/dpkg.log

Rotierte Protokolle müssen gegebenenfalls zusätzlich geprüft werden.

6. systemd-Gesamtzustand prüfen

Fehlgeschlagene Units:

systemctl --failed

Systemzustand:

systemctl is-system-running

Alle geladenen Dienste:

systemctl list-units --type=service --all

Installierte Unit-Dateien:

systemctl list-unit-files --type=service

Abweichende oder lokal angepasste Units:

systemd-delta

Ein System kann als degraded angezeigt werden, obwohl die vom Benutzer benötigte Anwendung funktioniert. Deshalb müssen die fehlgeschlagenen Units einzeln bewertet werden.

7. Dienststatus untersuchen

Beispieldienst:

systemctl status example.service

Aktivitätsstatus:

systemctl is-active example.service

Autostartstatus:

systemctl is-enabled example.service

Fehlerzustand:

systemctl is-failed example.service

Ausgewählte Eigenschaften:

systemctl show example.service \
    -p ActiveState \
    -p SubState \
    -p Result \
    -p ExecMainCode \
    -p ExecMainStatus \
    -p MainPID \
    -p User \
    -p Group \
    -p FragmentPath

Zu unterscheiden sind:

enabled bedeutet nicht, dass der Dienst gerade läuft. active bedeutet nicht automatisch, dass er beim nächsten Systemstart wieder gestartet wird.

8. Dienstprotokoll mit journalctl prüfen

Aktuelles Dienstprotokoll:

journalctl -u example.service

Nur aktueller Systemstart:

journalctl -u example.service -b

Vorheriger Systemstart:

journalctl -u example.service -b -1

Letzte 100 Einträge:

journalctl -u example.service -n 100

Fortlaufende Anzeige:

journalctl -u example.service -f

Bestimmter Zeitraum:

journalctl -u example.service \
    --since "2026-08-02 10:00:00" \
    --until "2026-08-02 11:00:00"

Warnungen und schwerere Meldungen des aktuellen Starts:

journalctl -b -p warning

Kernelmeldungen des aktuellen Starts:

journalctl -k -b

Ausführliche Ausgabe:

journalctl -u example.service -o verbose

Zu dokumentieren sind:

Die letzte Fehlermeldung muss nicht die eigentliche Ursache sein. Häufig steht die erste relevante Meldung weiter oben.

9. Klassische Protokolldateien

Je nach Distribution und Dienst können zusätzlich relevant sein:

/var/log/syslog
/var/log/messages
/var/log/auth.log
/var/log/secure
/var/log/kern.log
/var/log/audit/audit.log
/var/log/dmesg
/var/log/cron
/var/log/maillog

Anwendungsprotokolle befinden sich häufig unter:

/var/log/<Anwendung>/

Letzte Zeilen anzeigen:

tail -n 100 /var/log/syslog

Fortlaufend beobachten:

tail -f /var/log/example/application.log

Komprimierte rotierte Protokolle durchsuchen:

zgrep -i 'error' /var/log/example/application.log*.gz

Nicht jede Distribution verwendet alle genannten Dateien. Auf ausschließlich journalbasierten Systemen können einzelne klassische Protokolldateien fehlen.

10. Unit-Datei und Überschreibungen prüfen

Wirksame Unit einschließlich Drop-ins anzeigen:

systemctl cat example.service

Pfad und Drop-ins:

systemctl show example.service \
    -p FragmentPath \
    -p DropInPaths

Abhängigkeiten:

systemctl list-dependencies example.service

Umgekehrte Abhängigkeiten:

systemctl list-dependencies --reverse example.service

Startreihenfolge und Abhängigkeiten können beeinflusst werden durch:

After= legt eine Reihenfolge fest, erzeugt allein aber keine Startabhängigkeit.

11. systemd-Konfiguration verifizieren

Unit-Dateien prüfen:

systemd-analyze verify example.service

Nach einer Änderung an Unit-Dateien:

systemctl daemon-reload

daemon-reload lädt die systemd-Konfiguration neu. Es startet den betroffenen Dienst nicht automatisch neu.

Vor einem Neustart des Dienstes sind zu prüfen:

12. Anwendungsidentität prüfen

Der Dienst kann unter einem anderen Benutzer laufen als erwartet.

systemd-Konfiguration:

systemctl show example.service \
    -p User \
    -p Group \
    -p SupplementaryGroups \
    -p DynamicUser

Prozessbenutzer:

ps -eo user,group,pid,ppid,stat,lstart,cmd

Bestimmter Prozess:

ps -o user,group,pid,ppid,stat,lstart,cmd -p <PID>

Benutzerinformationen:

id exampleuser

Gruppen eines Benutzers:

id -nG exampleuser

Kontoeintrag:

getent passwd exampleuser

Gruppeneintrag:

getent group examplegroup

getent berücksichtigt die konfigurierte Namensdienstauflösung und ist deshalb bei LDAP-, Active-Directory- oder SSSD-Umgebungen häufig aussagekräftiger als das alleinige Lesen von /etc/passwd.

13. Prozesse untersuchen

Alle Prozesse:

ps aux

Hierarchische Darstellung:

ps -ef --forest

Prozesse eines Benutzers:

ps -u exampleuser -f

Prozess anhand des Namens suchen:

pgrep -a example

Prozessbaum:

pstree -ap

Dynamische Anzeige:

top

Falls installiert:

htop

Zu prüfen sind:

14. Prozesszustände bewerten

Wichtige Zustände in ps:

Zustand Bedeutung
R läuft oder ist ausführbar
S unterbrechbarer Schlafzustand
D nicht unterbrechbarer Schlafzustand, häufig I/O-bezogen
T angehalten oder verfolgt
Z Zombieprozess
I inaktiver Kernelthread

Ein Prozess im Zustand D kann häufig nicht sofort beendet werden, weil er auf eine Kernel- oder I/O-Operation wartet.

Ein Zombie verbraucht normalerweise kaum Ressourcen. Er zeigt jedoch, dass der Elternprozess den Beendigungsstatus des Kindprozesses noch nicht abgeholt hat.

15. Signale und Prozessbeendigung

Normale Beendigungsanforderung:

kill -TERM <PID>

Standardsignal von kill:

kill <PID>

Erzwungene Beendigung:

kill -KILL <PID>

Signale anzeigen:

kill -l

SIGTERM erlaubt einem Prozess eine kontrollierte Beendigung. SIGKILL kann nicht abgefangen werden und verhindert eine geordnete Bereinigung.

Vor einer Prozessbeendigung prüfen:

Ein von systemd verwalteter Prozess sollte normalerweise über die zuständige Unit und nicht ausschließlich über seine PID gesteuert werden.

16. Offene Dateien und Arbeitsverzeichnisse prüfen

Offene Dateien eines Prozesses:

lsof -p <PID>

Prozesse mit Zugriff auf eine Datei:

lsof /var/lib/example/data.db

Alternativ:

fuser -v /var/lib/example/data.db

Prozesse auf einem Mountpoint:

fuser -vm /mnt/data

Gelöschte, aber weiterhin geöffnete Dateien:

lsof +L1

Eine gelöschte Datei kann weiterhin Speicherplatz belegen, solange ein Prozess sie geöffnet hält. Der Speicher wird normalerweise erst nach dem Schließen des Deskriptors freigegeben.

17. Ausführbare Datei und Bibliotheken prüfen

Verwendete Binärdatei:

readlink -f /proc/<PID>/exe

Arbeitsverzeichnis:

readlink -f /proc/<PID>/cwd

Kommandozeile:

tr '\0' ' ' < /proc/<PID>/cmdline

Umgebungsvariablen, nur mit erforderlicher Berechtigung:

tr '\0' '\n' < /proc/<PID>/environ

Bibliotheksabhängigkeiten:

ldd /usr/local/bin/example

ldd sollte nicht ungeprüft auf nicht vertrauenswürdige ausführbare Dateien angewendet werden. Je nach Datei und Implementierung kann dabei ein Sicherheitsrisiko entstehen.

18. Anwendungskonfiguration prüfen

Zu prüfen sind:

Datei anzeigen:

sed -n '1,200p' /etc/example/application.conf

Dateieigenschaften:

stat /etc/example/application.conf

Viele Dienste besitzen einen eigenen Syntaxprüfer. Beispiele:

sshd -t

nginx -t

apachectl configtest

Der passende Prüfbefehl muss zur tatsächlich installierten Anwendung und Version passen.

19. Dateirechte prüfen

Lange Darstellung:

ls -la /var/lib/example

Numerische IDs:

ls -lan /var/lib/example

Alle Bestandteile eines Pfades prüfen:

namei -l /var/lib/example/data/file.db

Dateistatus:

stat /var/lib/example/data/file.db

ACL anzeigen:

getfacl /var/lib/example/data/file.db

Zu prüfen sind:

Für das Betreten eines Verzeichnisses wird das Ausführungsrecht benötigt. Ausreichende Rechte auf der Datei allein genügen nicht, wenn ein übergeordnetes Verzeichnis nicht durchlaufen werden darf.

20. Zugriff als Dienstbenutzer testen

Kontrollierter Lesetest:

sudo -u exampleuser -- test -r /var/lib/example/data/file.db

Schreibbarkeit eines Verzeichnisses:

sudo -u exampleuser -- test -w /var/lib/example/data

Pfadzugriff:

sudo -u exampleuser -- namei -l /var/lib/example/data/file.db

Ein Test sollte möglichst dieselbe Identität, denselben Pfad und dieselbe Aktion wie die Anwendung verwenden.

Keine produktiven Dateien ungeprüft verändern oder überschreiben. Für Schreibtests ist eine dafür vorgesehene Testdatei zu verwenden.

21. SELinux prüfen

Status:

getenforce

Ausführlicher Status:

sestatus

Dateikontext:

ls -lZ /var/lib/example

Prozesskontext:

ps -eZ

Aktuelle AVC-Meldungen:

ausearch \
    -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR \
    -ts recent

Auswertung, sofern setroubleshoot installiert ist:

sealert -a /var/log/audit/audit.log

Sollkontext eines Pfades prüfen:

matchpathcon /var/lib/example/data

Kontext anhand der Richtlinie wiederherstellen:

restorecon -Rv /var/lib/example

SELinux darf nicht pauschal deaktiviert werden, nur um eine Anwendung zum Laufen zu bringen. Eine Ablehnung weist häufig auf einen falschen Pfad, falsches Label, eine unpassende Dienstkonfiguration oder eine fehlende gezielte Richtlinie hin.

Ein Wechsel in den permissiven Modus verändert den Sicherheitszustand des gesamten Systems und ist keine harmlose Standarddiagnose.

22. AppArmor prüfen

Status:

aa-status

Kernel- und Auditmeldungen:

journalctl -k | grep -i apparmor

Je nach System:

grep -i apparmor /var/log/syslog

Mögliche Ursachen:

Ein Profil sollte nicht ungeprüft deaktiviert werden. Zuerst sind Ablehnung, betroffener Pfad und notwendige Mindestberechtigung zu bestimmen.

23. Port und Socket prüfen

Lauschende TCP- und UDP-Sockets:

ss -tulpn

Nur lauschende TCP-Sockets:

ss -ltnp

Bestimmter Port:

ss -ltnp 'sport = :443'

Bestehende TCP-Verbindungen:

ss -tanp

Unix-Sockets:

ss -lxnp

Zu unterscheiden sind:

24. Portkonflikt untersuchen

Belegung eines Ports:

ss -ltnp 'sport = :8080'

Alternativ:

lsof -nP -iTCP:8080 -sTCP:LISTEN

Mögliche Ursachen:

Ein Prozess darf nicht allein deshalb beendet werden, weil er den gewünschten Port belegt. Zuerst muss seine Funktion und Zuständigkeit geklärt werden.

25. Lokale Anwendungsfunktion prüfen

TCP-Verbindung:

nc -vz 127.0.0.1 8080

HTTP-Abfrage:

curl -v http://127.0.0.1:8080/

HTTPS einschließlich Zertifikatsprüfung:

curl -v https://server.example.local/

TLS-Verbindung untersuchen:

openssl s_client \
    -connect server.example.local:443 \
    -servername server.example.local

Bewertung:

Ergebnis Wahrscheinlicher Bereich
lokal kein Listener Dienst, Konfiguration oder Startfehler
lokal erreichbar, remote nicht Firewall, Routing, Bind-Adresse oder Netzwerk
TCP funktioniert, HTTP fehlerhaft Anwendung, Reverse Proxy oder Backend
HTTP über IP funktioniert, Name nicht DNS, Virtual Host, SNI oder Zertifikat
TLS schlägt fehl Zertifikat, Schlüssel, Protokoll oder Cipher
Antwort langsam Anwendung, Backend, DNS, Storage oder Ressourcen

26. Netzwerkkonfiguration prüfen

Adressen:

ip address show

Kurzform:

ip -br address

Links:

ip -br link

Routingtabelle:

ip route show

IPv6-Routen:

ip -6 route show

Route zu einem konkreten Ziel:

ip route get 192.0.2.20

Nachbarn:

ip neigh show

Netzwerkstatistik:

ip -s link show

Zu prüfen sind:

27. Namensauflösung prüfen

Resolverkonfiguration:

cat /etc/resolv.conf

Auf systemd-resolved-Systemen:

resolvectl status

Namensauflösung über NSS:

getent hosts server.example.local

DNS-Abfrage:

dig server.example.local

Bestimmten DNS-Server abfragen:

dig @192.0.2.53 server.example.local

Reverse Lookup:

dig -x 192.0.2.20

Zu unterscheiden sind:

28. Firewall prüfen

Je nach System können unterschiedliche Werkzeuge verwendet werden.

firewalld:

firewall-cmd --get-active-zones

firewall-cmd --list-all

nftables:

nft list ruleset

iptables-Kompatibilitätsansicht:

iptables -S

Zu prüfen sind:

Ein geöffneter Port in der Hostfirewall beweist nicht, dass vorgelagerte Firewalls, Routing oder die Anwendung funktionieren.

29. Paketmitschnitt

Beispiel für TCP-Port 443:

tcpdump -ni any tcp port 443

Bestimmter Host und Port:

tcpdump -ni any \
    host 192.0.2.20 and tcp port 443

In Datei schreiben:

tcpdump -ni any \
    -s 0 \
    -w /tmp/example-443.pcap \
    tcp port 443

Zu untersuchen sind:

Paketmitschnitte können vertrauliche IP-Adressen, Hostnamen, Nutzdaten, Tokens und Anmeldeinformationen enthalten und müssen geschützt gespeichert sowie kontrolliert gelöscht werden.

30. CPU und Load prüfen

Überblick:

uptime

Dynamische Prozessansicht:

top

Logische Prozessoren:

nproc

CPU-Informationen:

lscpu

Falls sysstat installiert ist:

mpstat -P ALL 1 5

Prozessbezogene Statistik:

pidstat 1 5

Load Average beschreibt nicht ausschließlich CPU-Auslastung. Je nach Linux-Zustand können auch Tasks in nicht unterbrechbarem Zustand zur Last beitragen.

Zu unterscheiden sind:

31. Arbeitsspeicher prüfen

Speicherübersicht:

free -h

Detaillierte Kernelwerte:

cat /proc/meminfo

Prozesse nach Speicherverbrauch:

ps aux --sort=-%mem | head

Falls verfügbar:

vmstat 1 5

Wichtige Unterscheidungen:

32. OOM Killer untersuchen

Kernelmeldungen:

journalctl -k -b | grep -Ei 'out of memory|oom|killed process'

Systemweites Journal:

journalctl -b | grep -Ei 'out of memory|oom|killed process'

Mögliche Ursachen:

Zu dokumentieren sind:

Ein automatischer Dienstneustart kann den OOM-Kill verdecken. Der Dienst erscheint anschließend wieder aktiv, obwohl die Ursache weiter besteht.

33. Swap prüfen

Aktive Swap-Bereiche:

swapon --show

Speicherübersicht:

free -h

Aktivität:

vmstat 1 10

Bei vmstat sind insbesondere zu beachten:

Swap darf nicht ungeprüft mit swapoff deaktiviert werden. Der Inhalt muss in den Arbeitsspeicher übernommen werden können; andernfalls drohen starke Last oder Fehler.

34. Speicherplatz prüfen

Dateisysteme:

df -hT

Bestimmter Pfad:

df -hT /var/lib/example

Verzeichnisgrößen:

du -xhd1 /var

Größte Unterverzeichnisse:

du -xhd1 /var |
    sort -h

Zu unterscheiden sind:

df und du können unterschiedliche Werte zeigen, beispielsweise wegen gelöschter, aber geöffneter Dateien oder wegen Mounts innerhalb des untersuchten Verzeichnisbaums.

35. Inodes prüfen

Inode-Nutzung:

df -ih

Ein Dateisystem kann freien Speicherplatz besitzen und trotzdem keine neuen Dateien mehr aufnehmen, wenn keine freien Inodes vorhanden sind.

Typische Ursachen:

Anzahl der Einträge in einem kontrollierten Verzeichnisbaum:

find /var/tmp/example -xdev -type f |
    wc -l

Bei sehr großen Verzeichnisbäumen kann bereits das Zählen erhebliche I/O-Last verursachen.

36. Mounts prüfen

Aktuelle Mounts:

findmnt

Bestimmter Pfad:

findmnt -T /var/lib/example

Blockgeräte und Dateisysteme:

lsblk -f

Persistente Konfiguration:

cat /etc/fstab

fstab-Konfiguration ohne tatsächliches Mounten prüfen:

findmnt --verify

systemd-Mount-Units:

systemctl list-units --type=mount --all

Zu prüfen sind:

Eine Anwendung kann scheinbar korrekt in einen lokalen Ordner schreiben, obwohl das vorgesehene Netzwerk- oder Datenvolume nicht eingehängt ist.

37. Schreibgeschütztes Dateisystem

Mountoptionen:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Kernelmeldungen:

journalctl -k -b |
    grep -Ei 'read-only|I/O error|filesystem|ext4|xfs'

Mögliche Ursachen:

Ein ungeprüftes Remount als rw kann eine bestehende Storage- oder Dateisystemstörung verschärfen. Zuerst müssen Kernelmeldungen und Datenträgerzustand bewertet werden.

38. Datenträger- und I/O-Fehler prüfen

Blockgeräte:

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Kernelmeldungen:

journalctl -k -b |
    grep -Ei 'I/O error|blk_update|reset|timeout|nvme|ata|scsi|ext4|xfs'

Falls sysstat installiert ist:

iostat -xz 1 5

S.M.A.R.T.-Informationen, sofern unterstützt:

smartctl -a /dev/sda

NVMe-Informationen, sofern das Werkzeug installiert ist:

nvme smart-log /dev/nvme0

Zu prüfen sind:

S.M.A.R.T.-Tests und Reparaturwerkzeuge können Last oder Zustandsänderungen verursachen. Sie sind nicht ungeprüft auf produktivem Storage auszuführen.

39. Dateisystemprüfung sicher planen

Dateisystemtyp feststellen:

findmnt -no FSTYPE,SOURCE,TARGET /var/lib/example

Ein klassisches fsck darf normalerweise nicht auf einem schreibend eingehängten Dateisystem ausgeführt werden.

Vor einer Reparatur sind zu klären:

Bei XFS, ext4, Btrfs und anderen Dateisystemen unterscheiden sich Diagnose- und Reparaturwerkzeuge erheblich.

40. LVM prüfen

Übersicht:

pvs

vgs

lvs

Ausführlicher:

lvs -a -o +devices

Zu prüfen sind:

Ein vergrößertes Logical Volume bedeutet nicht automatisch, dass auch das darin enthaltene Dateisystem vergrößert wurde.

41. Software-RAID prüfen

Status:

cat /proc/mdstat

Detailinformationen:

mdadm --detail /dev/md0

Zu prüfen sind:

Ein Rebuild erhöht die I/O-Last und ersetzt kein Backup. Ein zweiter Fehler während der Wiederherstellung kann je nach RAID-Level zum Datenverlust führen.

42. Netzwerk-Mounts prüfen

NFS-Mounts:

findmnt -t nfs,nfs4

SMB-/CIFS-Mounts:

findmnt -t cifs

RPC-Dienste eines NFS-Servers:

rpcinfo -p <Server>

NFS-Exporte, sofern erreichbar:

showmount -e <Server>

Zu prüfen sind:

Ein hängender Netzwerk-Mount kann Befehle wie df, du, ls oder Anwendungen blockieren.

43. Paketverwaltung prüfen

Debian- und Ubuntu-Systeme:

apt update

Installierten Paketstatus prüfen:

dpkg -l

Unterbrochene Paketkonfiguration:

dpkg --audit

RPM-basierte Systeme:

dnf check

Installiertes Paket bestimmen:

rpm -q <Paketname>

Datei einem Paket zuordnen:

rpm -qf /usr/bin/example

Debian-Paket zuordnen:

dpkg -S /usr/bin/example

Mögliche Ursachen:

Paketdatenbanken und Lockdateien dürfen nicht ungeprüft gelöscht werden. Zuerst ist zu bestimmen, ob ein legitimer Paketprozess aktiv ist.

44. Paketdateien verifizieren

RPM-Paket:

rpm -V <Paketname>

Debian- und Ubuntu-Systeme, falls debsums installiert ist:

debsums <Paketname>

Abweichungen können entstehen durch:

Eine Abweichung beweist allein weder einen Defekt noch eine Manipulation. Dateityp und erwartete lokale Anpassung müssen berücksichtigt werden.

45. Cronjobs prüfen

Systemweite Crontab:

cat /etc/crontab

Systemverzeichnisse:

ls -la /etc/cron.d/

Benutzer-Crontab:

crontab -l

Crontab eines anderen Benutzers:

sudo crontab -u exampleuser -l

Cron-Dienst:

systemctl status cron

Je nach Distribution:

systemctl status crond

Cron-Protokoll:

journalctl -u cron

Oder:

journalctl -u crond

Typische Ursachen:

Ein erfolgreicher manueller Skriptstart beweist nicht, dass der Cronjob mit seiner reduzierten Umgebung funktioniert.

46. systemd-Timer prüfen

Timer anzeigen:

systemctl list-timers --all

Bestimmten Timer:

systemctl status example.timer

Zugehörigen Dienst:

systemctl status example.service

Protokolle:

journalctl -u example.timer -u example.service

Konfiguration:

systemctl cat example.timer

Zu prüfen sind:

Der Timer kann erfolgreich ausgelöst haben, obwohl die zugehörige Service-Unit fehlgeschlagen ist.

47. Zeit und Zeitsynchronisation prüfen

Systemzeit:

date --iso-8601=seconds

Status:

timedatectl

Bei chrony:

chronyc tracking

chronyc sources -v

Bei systemd-timesyncd:

timedatectl timesync-status

Mögliche Auswirkungen falscher Zeit:

Die Zeit darf auf produktiven Datenbank-, Cluster- oder Authentifizierungssystemen nicht ungeprüft sprunghaft verändert werden.

48. Zertifikate prüfen

Zertifikatsdatei:

openssl x509 \
    -in /etc/example/server.crt \
    -noout \
    -subject \
    -issuer \
    -dates \
    -fingerprint

Private-Key-Dateirechte:

stat /etc/example/server.key

Zertifikat und Schlüssel vergleichen, beispielhaft für RSA:

openssl x509 \
    -noout \
    -modulus \
    -in /etc/example/server.crt |
    openssl sha256

openssl rsa \
    -noout \
    -modulus \
    -in /etc/example/server.key |
    openssl sha256

Zu prüfen sind:

Private Schlüssel dürfen nicht in Diagnoseprotokolle oder Tickets kopiert werden.

49. Kernelmeldungen prüfen

Aktueller Systemstart:

journalctl -k -b

Warnungen und Fehler:

journalctl -k -b -p warning

Klassische Anzeige:

dmesg --level=emerg,alert,crit,err,warn

Mögliche relevante Meldungen:

Der dmesg-Puffer kann ältere Meldungen überschreiben. Das persistente Journal oder ein zentraler Logserver kann deshalb zusätzliche Informationen liefern.

50. Kernelmodule und Hardware prüfen

Geladene Module:

lsmod

Modulinformationen:

modinfo <Modulname>

PCI-Geräte und Treiber:

lspci -k

USB-Geräte:

lsusb

Hardwareübersicht:

lscpu

lsblk

Mögliche Ursachen:

Kernelmodule dürfen nicht ungeprüft entladen werden. Ein Modul kann von Netzwerk-, Storage- oder anderen produktiven Geräten verwendet werden.

51. Bootfehler untersuchen

Bootzeit analysieren:

systemd-analyze

Langsame Units:

systemd-analyze blame

Kritische Kette:

systemd-analyze critical-chain

Fehlgeschlagene Units:

systemctl --failed

Protokoll des aktuellen Starts:

journalctl -b

Protokoll des vorherigen Starts:

journalctl -b -1

Verfügbare Starts:

journalctl --list-boots

Zu prüfen sind:

52. Unerwarteten Neustart oder Absturz prüfen

Letzte Neustarts:

last reboot

Vorheriger Boot:

journalctl -b -1 -e

Kernelmeldungen des vorherigen Boots:

journalctl -k -b -1

Mögliche Ursachen:

Fehlende Abschlussmeldungen im Journal können auf einen abrupten Ausfall hinweisen, beweisen aber keine bestimmte Ursache.

53. Hängendes System und Hung Tasks

Nach Meldungen suchen:

journalctl -k |
    grep -Ei 'blocked for more than|hung task|soft lockup|hard lockup'

Mögliche Ursachen:

Magic SysRq kann in schweren Störungsfällen Diagnose- oder Notfallfunktionen auslösen. Die verfügbaren Funktionen hängen von Kernelkonfiguration und Systemwerten ab.

Status:

cat /proc/sys/kernel/sysrq

SysRq-Aktionen können erhebliche Auswirkungen bis hin zu Prozessbeendigung oder Neustart besitzen. Sie dürfen nur nach einem dafür vorgesehenen Notfallverfahren verwendet werden.

54. Strace als gezielte Tiefenanalyse

Systemaufrufe eines gestarteten Programms:

strace -f -o /tmp/example.strace <Befehl>

An laufenden Prozess anhängen:

strace -f -p <PID>

Nach Dateioperationen filtern:

strace -f -e trace=file <Befehl>

Nach Netzwerkoperationen filtern:

strace -f -e trace=network <Befehl>

Zu erkennen sind beispielsweise:

strace kann Leistung und Zeitverhalten beeinflussen sowie vertrauliche Dateinamen, Argumente und Daten sichtbar machen.

55. Typische Fehlerbilder

Symptom Mögliche Ursache Nächster Test
Dienst startet nicht Syntax, Rechte, Abhängigkeit oder fehlende Datei systemctl status, journalctl -u
Dienst beendet sich sofort Anwendung meldet Fehler oder Prozess forkt anders als erwartet Journal und ExecMainStatus
Dienst ist active, Anwendung funktioniert nicht interner Fehler, falscher Port oder Backend gestört ss, curl, Anwendungslog
Dienst ist failed, Prozess läuft Prozess wurde außerhalb von systemd gestartet ps, systemctl show
Dienst startet nach Reboot nicht nicht aktiviert oder Boot-Abhängigkeit fehlerhaft is-enabled, Bootjournal
Dienst läuft als falscher Benutzer Unit oder Drop-in geändert systemctl cat, systemctl show
Konfigurationsänderung wirkt nicht falsche Datei oder kein Reload/Restart Prozessargumente und Unit prüfen
Port ist nicht geöffnet Dienststart oder Bind-Konfiguration ss -ltnp
Port ist nur lokal erreichbar Bind-Adresse oder Firewall ss, Firewall, Remote-Test
Port bereits belegt zweite Instanz oder anderer Dienst ss, lsof
Zugriff verweigert Unix-Rechte, ACL, SELinux oder AppArmor namei, getfacl, Auditlog
Datei nicht gefunden, obwohl sie existiert falscher Namespace, Mount oder Pfadbestandteil namei, findmnt, Prozessumgebung
Schreiben schlägt fehl Rechte, ro, Speicher oder Inodes test -w, findmnt, df -h, df -i
df zeigt voll, du nicht gelöschte offene Datei oder reservierter Bereich lsof +L1
du hängt Netzwerk-Mount oder Storageproblem findmnt, Prozesszustand, Kerneljournal
hohe Load bei geringer CPU I/O-Wait oder Tasks im Zustand D vmstat, iostat, ps
Prozess wurde unerwartet beendet OOM, Signal oder Crash Kernel- und Dienstjournal
Server nutzt Swap stark früherer oder aktueller Speicherdruck vmstat, free, Prozessspeicher
keine neuen Dateien trotz freiem Speicher Inodes erschöpft df -ih
Mount fehlt nach Neustart fstab, Abhängigkeit oder Gerät fehlt findmnt --verify, Bootjournal
Dateisystem plötzlich read-only I/O- oder Dateisystemfehler Kerneljournal
Cronjob läuft manuell, aber nicht automatisch Umgebung, Benutzer, Pfad oder Shell Cronlog und kontrollierter Umgebungstest
systemd-Timer löst aus, Aufgabe scheitert zugehörige Service-Unit fehlerhaft Journal beider Units
TLS-Zertifikat angeblich abgelaufen falsche Zeit oder altes geladenes Zertifikat timedatectl, openssl s_client
Paketupdate schlägt fehl Repository, DNS, Signatur oder Lock Paketmanager- und Prozessstatus
Server startet langsam Mount-, Netzwerk- oder Unit-Timeout systemd-analyze critical-chain
Netzwerk funktioniert nach IP, nicht nach Name DNS oder NSS getent hosts, dig

56. Vorgehensweise bei „Dienst startet nicht“

  1. Host, Dienstname und Zeitpunkt dokumentieren.
  2. systemctl status auswerten.
  3. systemctl show auf Ergebnis und Exit-Status prüfen.
  4. Dienstjournal seit dem letzten Startversuch lesen.
  5. erste relevante Fehlermeldung bestimmen.
  6. tatsächlich verwendete Unit und Drop-ins anzeigen.
  7. Startbenutzer und Gruppen prüfen.
  8. Anwendungskonfiguration mit dem vorgesehenen Syntaxprüfer testen.
  9. benötigte Dateien und Pfade prüfen.
  10. Unix-Rechte, ACL und alle Pfadbestandteile prüfen.
  11. SELinux- oder AppArmor-Ablehnungen prüfen.
  12. Portkonflikte prüfen.
  13. Mounts und externe Abhängigkeiten prüfen.
  14. Speicherplatz, Inodes, RAM und Limits kontrollieren.
  15. genau eine nachgewiesene Ursache korrigieren.
  16. Dienst kontrolliert starten.
  17. Journal, Prozess, Port und Anwendungsfunktion nachkontrollieren.
  18. Ursache, Maßnahme und Rückweg dokumentieren.

57. Vorgehensweise bei „Server ist langsam“

  1. Zeitraum und konkrete langsame Funktion erfassen.
  2. Vergleichswert oder normalen Zustand bestimmen.
  3. Load, CPU, RAM und Swap prüfen.
  4. Prozesse nach CPU- und Speicherverbrauch sortieren.
  5. Prozesszustände und blockierte Tasks prüfen.
  6. vmstat auswerten.
  7. I/O-Latenz und Datenträgerauslastung prüfen.
  8. Kernelmeldungen auf Storage- oder Treiberfehler untersuchen.
  9. Netzwerkfehler, Drops und Retransmissions berücksichtigen.
  10. DNS-Antwortzeiten prüfen.
  11. Anwendung und Backend getrennt testen.
  12. cgroup-, Container- oder Unit-Limits prüfen.
  13. geplante Jobs, Backups und Updates berücksichtigen.
  14. Engpass anhand von Messwerten nachweisen.
  15. eine kontrollierte Maßnahme durchführen.
  16. dieselbe Funktion mit denselben Messwerten erneut testen.

58. Vorgehensweise bei „Kein Speicherplatz“

  1. betroffenen Pfad dokumentieren.
  2. zugehöriges Dateisystem mit findmnt -T bestimmen.
  3. Speicherplatz mit df -hT prüfen.
  4. Inodes mit df -ih prüfen.
  5. Quotas und Storage-Limits berücksichtigen.
  6. Verzeichnisgrößen innerhalb desselben Dateisystems untersuchen.
  7. gelöschte offene Dateien mit lsof +L1 prüfen.
  8. Logs, Caches, temporäre Dateien und Containerdaten unterscheiden.
  9. LVM-Thin-Pool oder Snapshotbereich prüfen.
  10. Ursache des Wachstums bestimmen.
  11. Aufbewahrungs- und Löschregeln prüfen.
  12. keine unbekannten Dateien pauschal löschen.
  13. eine kontrollierte Bereinigung oder Erweiterung durchführen.
  14. Anwendung und Speicherzustand erneut prüfen.
  15. Präventionsmaßnahme wie Rotation, Monitoring oder Quota dokumentieren.

59. Vorgehensweise bei „Dateisystem oder Mount nicht verfügbar“

  1. betroffenen Mountpoint dokumentieren.
  2. findmnt und lsblk -f auswerten.
  3. Blockgerät, UUID und Dateisystemtyp bestimmen.
  4. /etc/fstab prüfen.
  5. findmnt --verify ausführen.
  6. systemd-Mount-Unit und Journal prüfen.
  7. Kernelmeldungen auf I/O-Fehler untersuchen.
  8. bei Netzwerk-Mounts DNS, Route, Port und Server prüfen.
  9. offene Prozesse und Abhängigkeiten berücksichtigen.
  10. Storage-, RAID-, LVM- oder Multipath-Zustand prüfen.
  11. Backup und Wartungsfenster klären.
  12. nur die nachgewiesene Ursache korrigieren.
  13. Mount kontrolliert herstellen.
  14. Lese- und Schreibfunktion entsprechend dem Sollzustand testen.
  15. Neustartverhalten gesondert verifizieren.

60. Maßnahmen und Rückwege

Ursache: Syntaxfehler in der Dienstkonfiguration

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falsche Dateiberechtigung

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: falscher SELinux-Kontext

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: Portkonflikt

Nachweis:

Maßnahme:

Rollback:

Verifikation:

Ursache: gelöschte offene Logdatei belegt Speicher

Nachweis:

Maßnahme:

Rollback:

Verifikation:

61. Nachkontrolle

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

62. Dokumentationsbeispiel

Symptom:
Der Dienst example-api ließ sich nach einem Konfigurationsupdate nicht mehr
starten. Clients erhielten „Connection refused“ auf TCP-Port 8443.

Zeitpunkt:
02.08.2026, 11:42 Uhr MESZ

Server:
linux-app-01.example.local

Dienst:
example-api.service

Nachweis:
systemctl status zeigte den Zustand „failed“.
Im Journal war unmittelbar nach dem Startversuch ein Berechtigungsfehler für
/etc/example-api/server.key dokumentiert.
Der Dienst lief als Benutzer example-api.
Ein kontrollierter Lesetest als example-api schlug fehl.
Die übergeordneten Verzeichnisse waren zugänglich.
Es gab keine passende SELinux- oder AppArmor-Ablehnung.
Die Schlüsseldatei war nach dem Austausch irrtümlich root:root mit Modus 0600
zugeordnet worden.

Ursache:
Die neue private Schlüsseldatei besaß nicht den vorgesehenen Gruppeneigentümer.
Der Dienstbenutzer konnte sie deshalb nicht lesen.

Maßnahme:
Nach Dokumentation des Ausgangszustands wurde die Datei der vorgesehenen
Dienstgruppe zugeordnet. Der Modus blieb auf das erforderliche Minimum
beschränkt.

Rollback:
Der ursprüngliche Eigentümer und die ursprüngliche Gruppe wurden dokumentiert
und können wiederhergestellt werden.

Verifikation:
Der Konfigurationstest war erfolgreich.
Der Dienst startete ohne neue Fehlermeldung.
TCP-Port 8443 wurde durch den vorgesehenen Prozess geöffnet.
Die lokale und externe HTTPS-Prüfung waren erfolgreich.
Der private Schlüssel ist weiterhin nicht für andere Benutzer lesbar.

Prävention:
Der Zertifikatsaustausch wird künftig durch einen dokumentierten Ablauf mit
Kontrolle von Eigentümer, Gruppe, Modus, Sicherheitskontext und anschließendem
Konfigurationstest durchgeführt.

63. Entscheidungsbaum

Linux-Dienst oder Anwendung gestört
        ↓
Ist das System erreichbar und die Zeit plausibel?
        ├── Nein
        │   ↓
        │   Boot, Netzwerk, Routing, DNS und Zeit prüfen
        │
        └── Ja
            ↓
Ist die Unit aktiv?
        ├── Nein
        │   ↓
        │   Status, Exit-Code und Dienstjournal prüfen
        │
        └── Ja
            ↓
Läuft der erwartete Prozess unter der richtigen Identität?
        ├── Nein
        │   ↓
        │   Unit, Drop-ins, Benutzer und Startmethode prüfen
        │
        └── Ja
            ↓
Lauscht die Anwendung auf der vorgesehenen Adresse und dem Port?
        ├── Nein
        │   ↓
        │   Konfiguration, Portkonflikt und Socket-Aktivierung prüfen
        │
        └── Ja
            ↓
Funktioniert die Anwendung lokal?
        ├── Nein
        │   ↓
        │   Anwendung, Backend, Rechte, Mounts und Ressourcen prüfen
        │
        └── Ja
            ↓
Funktioniert der Zugriff über das Netzwerk?
        ├── Nein
        │   ↓
        │   Bind-Adresse, Firewall, Route, DNS und Paketfluss prüfen
        │
        └── Ja
            ↓
Benutzerfunktion, Lastverhalten und abhängige Systeme prüfen

64. Typische Prüfungsfragen

Warum reicht der Zustand active eines systemd-Dienstes nicht als vollständiger Funktionsnachweis?

Antwort anzeigen

Der Zustand zeigt, dass systemd die Unit als aktiv betrachtet. Er beweist nicht, dass die Anwendung auf dem richtigen Port lauscht, ihre Backends erreicht oder korrekte Antworten auf Benutzeranfragen liefert.

Worin unterscheiden sich enabled und active?

Antwort anzeigen

enabled beschreibt die Einbindung für einen automatischen Start. active beschreibt den aktuellen Laufzeitzustand. Ein Dienst kann aktiv und gleichzeitig nicht aktiviert sein oder aktiviert, aber aktuell fehlgeschlagen sein.

Warum sollte zuerst SIGTERM und nicht sofort SIGKILL verwendet werden?

Antwort anzeigen

SIGTERM ermöglicht dem Prozess eine kontrollierte Beendigung, beispielsweise das Schreiben von Daten und Schließen von Dateien. SIGKILL kann nicht behandelt werden und verhindert eine geordnete Bereinigung.

Warum können df und du unterschiedliche Speicherbelegungen anzeigen?

Antwort anzeigen

Eine häufige Ursache sind gelöschte Dateien, die von einem laufenden Prozess weiterhin geöffnet gehalten werden. du findet sie nicht mehr im Verzeichnisbaum, während das Dateisystem den belegten Speicher weiterhin berücksichtigt.

Warum kann ein Dateisystem trotz freiem Speicherplatz keine neue Datei aufnehmen?

Antwort anzeigen

Die verfügbaren Inodes können erschöpft sein. In diesem Fall ist noch Datenkapazität frei, aber es können keine weiteren Dateisystemobjekte angelegt werden.

Warum beweist ein erfolgreicher manueller Skriptstart nicht, dass ein Cronjob funktioniert?

Antwort anzeigen

Cron verwendet häufig eine reduzierte Umgebung, einen anderen Benutzer, ein anderes Arbeitsverzeichnis und eine eingeschränkte PATH-Variable. Das Skript kann deshalb manuell funktionieren und automatisch scheitern.

Warum sollte SELinux nicht pauschal deaktiviert werden?

Antwort anzeigen

Dadurch wird eine wichtige Sicherheitsschicht für das gesamte System entfernt, ohne die eigentliche Ursache zu beheben. Stattdessen müssen Ablehnung, Pfad, Dateikontext und notwendige Mindestberechtigung untersucht werden.

Was bedeutet ein Prozess im Zustand D?

Antwort anzeigen

Der Prozess befindet sich in einem nicht unterbrechbaren Schlafzustand und wartet häufig auf eine I/O- oder Kerneloperation. Die zugrunde liegende Storage-, Mount- oder Treiberstörung muss untersucht werden.

Warum kann ein fehlender Mount zu Daten am falschen Ort führen?

Antwort anzeigen

Wenn der vorgesehene Mount fehlt, bleibt das lokale Mountpoint-Verzeichnis sichtbar. Eine Anwendung kann dann unbemerkt in das lokale Root-Dateisystem statt auf das vorgesehene Volume schreiben.

65. Prüfungsfallen

66. Checkliste

67. Schnellreferenz

Beobachtung Nächstes Werkzeug
Betriebssystemversion unklar cat /etc/os-release
Kernelversion unklar uname -r
Systemzustand unklar systemctl is-system-running
fehlgeschlagene Units gesucht systemctl --failed
Dienststatus unklar systemctl status
Exit-Code unklar systemctl show
Dienstprotokoll gesucht journalctl -u
vorheriger Boot relevant journalctl -b -1
tatsächliche Unit unklar systemctl cat
Drop-ins vermutet systemctl show -p DropInPaths
Unit-Syntax unklar systemd-analyze verify
Prozess gesucht pgrep -a, ps
Prozessbaum benötigt pstree -ap
offene Datei unklar lsof, fuser
gelöschte Datei belegt Speicher lsof +L1
Dienstbenutzer unklar systemctl show -p User -p Group
Benutzergruppen unklar id, getent
Pfadberechtigung unklar namei -l, stat
ACL unklar getfacl
SELinux-Status unklar getenforce, sestatus
SELinux-Ablehnung vermutet ausearch
AppArmor-Ablehnung vermutet aa-status, Kerneljournal
Listener unklar ss -ltnp
Portkonflikt vermutet ss, lsof
lokale HTTP-Funktion unklar curl -v
TLS-Fehler openssl s_client
IP-Konfiguration unklar ip -br address
Route unklar ip route get
DNS-Auflösung unklar getent hosts, dig
Firewallzustand unklar firewall-cmd, nft
Paketfluss unklar tcpdump
CPU-Last unklar top, mpstat, pidstat
RAM unklar free -h, vmstat
OOM vermutet journalctl -k
Swap unklar swapon --show, vmstat
Speicherplatz unklar df -hT
Verzeichnisgröße unklar du -xhd1
Inodes unklar df -ih
Mount unklar findmnt
Blockgerät unklar lsblk -f
fstab fehlerhaft vermutet findmnt --verify
I/O-Fehler vermutet Kerneljournal, iostat
LVM-Zustand unklar pvs, vgs, lvs
Software-RAID unklar /proc/mdstat, mdadm --detail
Paketdatei verändert rpm -V, debsums
Cronjob unklar Crontab und Cronjournal
systemd-Timer unklar systemctl list-timers --all
Zeitsynchronisation unklar timedatectl, chronyc
Boot langsam systemd-analyze critical-chain
Systemaufruf scheitert strace

Merksatz

Auf einem Linux-Server wird vom objektiven Symptom über Unit, Prozess, Protokoll, Identität, Port und Abhängigkeiten bis zu Berechtigungen, Sicherheitsrichtlinien, Ressourcen, Mounts und Kernel geprüft. Ein Dienst wird erst verändert oder neu gestartet, wenn der Fehlerzustand gesichert, die Auswirkung bewertet und ein Rückweg festgelegt wurde. active, ein offener Port und ein erfolgreicher lokaler Test sind jeweils nur Teilnachweise – entscheidend ist die ursprüngliche Benutzerfunktion.

Quellen und weiterführende Dokumentation

Offizielle systemd-Dokumentation

Offizielle Linux-Kernel-Dokumentation

Offizielle Red-Hat-Dokumentation

Offizielle Ubuntu-Dokumentation

Linux-Handbuchseiten

Revision #2
Created 2 August 2026 12:03:01 by Admin
Updated 2 August 2026 12:22:24 by Admin