9.1 Logs, Monitoring und Fehlersuche
Logs und Monitoring sind zentrale Werkzeuge, um Linux-Systeme zu überwachen, Fehler zu finden und Sicherheitsereignisse nachzuvollziehen.
Unter Linux werden viele Ereignisse protokolliert:
- Systemstarts
- Dienststarts
- Fehler
- Warnungen
- Anmeldungen
- SSH-Zugriffe
- Kernelmeldungen
- Paketinstallationen
- Netzwerkprobleme
- Sicherheitsereignisse
Für Fachinformatiker Systemintegration ist dieses Thema besonders wichtig, weil man im Serverbetrieb nicht nur Befehle ausführt, sondern Probleme gezielt anhand von Logs, Messwerten und Statusinformationen eingrenzen muss.
Merksatz:
Gute Fehlersuche basiert auf Logs,
Messwerten
und systematischer Eingrenzung.
Lernziele
Nach dieser Seite solltest du erklären können:
- was Logs sind
- wo Linux-Logs häufig liegen
- was journalctl macht
- was /var/log enthält
- wie man Dienstlogs prüft
- wie man aktuelle Logeinträge live mitliest
- wie man CPU,
RAM,
Speicher
und Prozesse prüft
- wie man typische Fehlerbilder systematisch eingrenzt
- warum Monitoring wichtig ist
- was Alerting bedeutet
Grundidee
Logs sind Protokolle von Ereignissen.
Sie helfen bei Fragen wie:
- Warum startet ein Dienst nicht?
- Warum schlägt eine Anmeldung fehl?
- Warum ist ein Server langsam?
- Warum ist Speicher voll?
- Warum wird eine Verbindung blockiert?
- Wann trat der Fehler erstmals auf?
- Welcher Benutzer war beteiligt?
- Welche Meldung schreibt der Dienst?
Merksatz:
Logs beantworten oft:
was,
wann,
wo
und warum etwas passiert ist.
Typische Logquellen
| Quelle | Bedeutung |
|---|---|
| systemd-Journal | zentrale systemd-Logs |
| /var/log | klassische Logdateien |
| Dienstlogs | Logs einzelner Anwendungen |
| Kernelmeldungen | Hardware, Treiber, Kernel |
| Authentifizierungslogs | Login, sudo, SSH |
| Paketmanager-Logs | Installationen und Updates |
| Webserver-Logs | HTTP-Zugriffe und Fehler |
| Firewall-Logs | erlaubter oder blockierter Verkehr |
| Anwendungslogs | Fehler und Ereignisse von Anwendungen |
Merksatz:
Nicht alle Logs liegen an derselben Stelle.
/var/log
Viele klassische Logdateien liegen unter:
/var/log
Beispiele:
| Pfad | Bedeutung |
|---|---|
| /var/log/syslog | allgemeine Systemmeldungen, häufig Debian/Ubuntu |
| /var/log/messages | allgemeine Systemmeldungen, häufig RHEL/Fedora-Umfeld |
| /var/log/auth.log | Authentifizierung, häufig Debian/Ubuntu |
| /var/log/secure | Authentifizierung, häufig RHEL/Fedora-Umfeld |
| /var/log/kern.log | Kernelmeldungen, je nach Distribution |
| /var/log/dmesg | Boot- und Kernelmeldungen, je nach Distribution |
| /var/log/nginx | Nginx-Logs |
| /var/log/apache2 | Apache-Logs |
| /var/log/apt | apt-Logs |
| /var/log/journal | dauerhaftes systemd-Journal, falls aktiviert |
Wichtig:
Welche Dateien vorhanden sind,
hängt von Distribution,
Diensten
und Logging-Konfiguration ab.
Merksatz:
/var/log ist der klassische Ort für Logdateien.
systemd-Journal
Auf vielen modernen Linux-Systemen sammelt systemd Logs im Journal.
Das Journal enthält unter anderem:
- Systemmeldungen
- Dienstmeldungen
- Bootmeldungen
- Fehler
- Warnungen
- Logs einzelner Units
Auswertung mit:
journalctl
Merksatz:
journalctl liest das systemd-Journal.
journalctl Grundlagen
Alle Journal-Einträge anzeigen:
journalctl
Letzte Einträge anzeigen:
journalctl -n 50
Live mitlesen:
journalctl -f
Logs seit letztem Boot:
journalctl -b
Logs eines Dienstes:
journalctl -u ssh
Live-Logs eines Dienstes:
journalctl -u ssh -f
Merksatz:
journalctl ist eines der wichtigsten Werkzeuge für Linux-Fehlersuche.
Dienstlogs mit journalctl
Wenn ein Dienst Probleme macht, prüft man zuerst:
systemctl status dienstname
Dann:
journalctl -u dienstname
Beispiel:
systemctl status nginx
journalctl -u nginx
Nur letzte Einträge:
journalctl -u nginx -n 50
Live mitlesen:
journalctl -u nginx -f
Seit letztem Boot:
journalctl -u nginx -b
Merksatz:
Dienstproblem:
status prüfen,
dann journalctl -u.
Zeitfilter bei journalctl
journalctl kann nach Zeit filtern.
Beispiele:
journalctl --since "1 hour ago"
journalctl --since "today"
journalctl --since "2026-07-08 10:00"
journalctl --until "2026-07-08 12:00"
Kombiniert mit Dienst:
journalctl -u ssh --since "today"
Merksatz:
Zeitfilter helfen,
Fehler auf einen Zeitraum einzugrenzen.
Prioritäten bei journalctl
Logs haben Prioritäten.
Nur Fehler anzeigen:
journalctl -p err
Warnungen und Schlimmeres anzeigen:
journalctl -p warning
Häufige Prioritäten:
| Priorität | Bedeutung |
|---|---|
| emerg | System unbenutzbar |
| alert | sofortiges Eingreifen nötig |
| crit | kritischer Fehler |
| err | Fehler |
| warning | Warnung |
| notice | Hinweis |
| info | Information |
| debug | Debug-Ausgabe |
Merksatz:
journalctl -p err zeigt Fehler.
dmesg
dmesg zeigt Kernelmeldungen.
Befehl:
dmesg
Menschenlesbare Zeitstempel:
dmesg -T
Typische Inhalte:
- Hardwareerkennung
- Treiberprobleme
- USB-Geräte
- Festplattenfehler
- Kernelwarnungen
- Netzwerkadapter
- Dateisystemfehler
Merksatz:
dmesg hilft bei Kernel-,
Hardware-
und Treiberproblemen.
Logdateien mit less lesen
Lange Logdateien liest man besser mit less.
Beispiel:
less /var/log/syslog
In less suchen:
/error
Nächster Treffer:
n
Verlassen:
q
Merksatz:
less ist besser als cat für lange Logs.
Logdateien live mitlesen
Mit tail kann man neue Logeinträge live verfolgen.
Beispiel:
tail -f /var/log/syslog
Letzte 100 Zeilen und live weiter:
tail -n 100 -f /var/log/syslog
Typische Nutzung:
Dienst neu starten
gleichzeitig Logs beobachten
Fehler direkt sehen
Merksatz:
tail -f liest neue Logeinträge live mit.
grep in Logs
Mit grep sucht man gezielt nach Begriffen.
Beispiele:
grep -i "error" /var/log/syslog
grep -i "failed" /var/log/auth.log
grep -i "denied" /var/log/auth.log
Mit Zeilennummer:
grep -n "error" datei.log
Groß-/Kleinschreibung ignorieren:
grep -i "error" datei.log
Merksatz:
grep filtert relevante Logzeilen.
Typische Suchbegriffe in Logs
| Suchbegriff | Mögliche Bedeutung |
|---|---|
| error | Fehler |
| failed | fehlgeschlagen |
| denied | verweigert |
| refused | abgelehnt |
| timeout | Zeitüberschreitung |
| not found | nicht gefunden |
| permission | Rechteproblem |
| authentication | Anmeldung |
| invalid | ungültig |
| disconnect | Verbindung getrennt |
| no space | Speicherproblem |
| read-only | nur lesbares Dateisystem |
Merksatz:
Gute Suchbegriffe beschleunigen Logauswertung.
Logrotation
Logs wachsen mit der Zeit.
Damit sie nicht unbegrenzt Speicher verbrauchen, werden sie rotiert.
Logrotation bedeutet:
alte Logs werden umbenannt,
komprimiert,
gelöscht
oder archiviert.
Typisches Werkzeug:
logrotate
Beispielhafte rotierte Dateien:
syslog
syslog.1
syslog.2.gz
Merksatz:
Logrotation verhindert,
dass Logs den Speicher füllen.
Warum Logs Speicher füllen können
Logs können sehr groß werden, wenn:
ein Dienst ständig Fehler schreibt
Debug-Logging aktiviert ist
Angriffe viele Einträge erzeugen
Logrotation nicht funktioniert
ein Dienst in einer Fehlerschleife hängt
Folgen:
Dateisystem voll
Dienste können nicht schreiben
Updates schlagen fehl
System wird instabil
Prüfen:
df -h
du -sh /var/log
Merksatz:
Viele Logs können Ursache und Folge eines Problems sein.
Monitoring
Monitoring bedeutet:
Systeme,
Dienste
Ressourcen
und Zustände regelmäßig überwachen.
Überwacht werden zum Beispiel:
- CPU
- RAM
- Speicherplatz
- Inodes
- Netzwerk
- Dienste
- Ports
- Antwortzeiten
- Backups
- Zertifikate
- Logs
- Sicherheitsereignisse
Merksatz:
Monitoring soll Probleme erkennen,
bevor Benutzer sie melden.
Alerting
Alerting bedeutet:
Bei bestimmten Ereignissen oder Grenzwerten wird eine Benachrichtigung ausgelöst.
Beispiele:
Speicher über 90 Prozent
Backup fehlgeschlagen
Dienst nicht erreichbar
Zertifikat läuft bald ab
CPU dauerhaft sehr hoch
viele fehlgeschlagene Logins
Wichtig:
Alarme müssen sinnvoll sein.
Zu viele unwichtige Alarme führen zu Alarmmüdigkeit.
Merksatz:
Alerting macht aus Monitoring eine aktive Warnung.
Wichtige Systemwerte
| Wert | Warum wichtig? |
|---|---|
| CPU | hohe Last kann Dienste verlangsamen |
| RAM | Speichermangel führt zu Swap oder Fehlern |
| Swap | starke Nutzung kann System verlangsamen |
| Speicherplatz | volle Dateisysteme verhindern Schreibzugriffe |
| Inodes | zu viele Dateien verhindern neue Dateien |
| Load Average | zeigt Systemlast |
| Netzwerk | Verbindungsprobleme oder Paketverlust |
| Dienststatus | zeigt, ob Dienste laufen |
| Logs | zeigen Ursachen und Fehler |
Merksatz:
Langsame Systeme brauchen Messwerte,
keine Vermutungen.
CPU und Prozesse prüfen
Prozesse und CPU prüfen mit:
top
oder:
htop
Prozesse anzeigen:
ps aux
Nach Prozess suchen:
ps aux | grep nginx
Mögliche Ursachen hoher CPU:
hohe Nutzerlast
Endlosschleife
fehlerhafter Prozess
Angriff
falsche Konfiguration
Merksatz:
Hohe CPU immer pro Prozess einordnen.
RAM und Swap prüfen
RAM prüfen:
free -h
Live prüfen:
top
Swap prüfen:
swapon --show
Mögliche Fehlerbilder:
System langsam
Prozesse werden beendet
starke Swap-Nutzung
Dienst startet nicht
Out-of-Memory-Ereignis
Merksatz:
Swap ist langsamer als RAM.
Viel Swap kann System stark verlangsamen.
Out of Memory
Wenn der Arbeitsspeicher knapp wird, kann Linux Prozesse beenden, um das System zu stabilisieren.
Das nennt man häufig:
OOM
oder:
Out of Memory
Suchen in Logs:
journalctl -k | grep -i "out of memory"
dmesg -T | grep -i "killed process"
Merksatz:
Wenn Prozesse plötzlich verschwinden,
OOM in Kernelmeldungen prüfen.
Speicherplatz prüfen
Dateisysteme prüfen:
df -h
Inodes prüfen:
df -i
Große Ordner prüfen:
du -sh /var/log
du -sh /var/lib
du -sh /home/*
Typische Ursachen:
Logs
Backups
Datenbanken
Container-Images
Cache
temporäre Dateien
Merksatz:
No space left on device:
df -h und df -i prüfen.
Netzwerk prüfen
IP-Adressen:
ip addr
Routen:
ip route
Gateway testen:
ping -c 4 gateway-ip
DNS prüfen:
dig example.com
Ports prüfen:
ss -tulpen
Webdienst prüfen:
curl -I http://localhost
Merksatz:
Netzwerkfehler Schritt für Schritt prüfen:
IP,
Route,
DNS,
Port,
Dienst.
Dienststatus prüfen
Dienststatus:
systemctl status dienstname
Autostart prüfen:
systemctl is-enabled dienstname
Aktiv prüfen:
systemctl is-active dienstname
Logs prüfen:
journalctl -u dienstname
Merksatz:
Dienstfehler:
systemctl status
und journalctl -u.
HTTP-Fehler einordnen
| Code | Bedeutung | Wahrscheinliche Richtung |
|---|---|---|
| 200 | OK | Dienst antwortet |
| 301 / 302 | Weiterleitung | Webserver oder Anwendung |
| 401 | nicht authentifiziert | Login fehlt oder falsch |
| 403 | verboten | Rechteproblem |
| 404 | nicht gefunden | Pfad oder Ressource falsch |
| 500 | interner Serverfehler | Anwendung oder Backend |
| 502 | Bad Gateway | Proxy erreicht Backend nicht |
| 503 | Dienst nicht verfügbar | Backend oder Dienst nicht bereit |
Merksatz:
HTTP-Code zeigt,
auf welcher Ebene man weiter suchen sollte.
Fehlersuche nach Änderung
Wenn ein Fehler direkt nach einer Änderung auftritt, ist diese Änderung besonders relevant.
Mögliche Änderungen:
Update
Konfigurationsänderung
Firewall-Regel
Rechteänderung
Zertifikatswechsel
Mountänderung
DNS-Änderung
Neustart
Sinnvolle Fragen:
Was wurde geändert?
Wann wurde geändert?
Wer hat geändert?
Gibt es ein Backup?
Gibt es einen Rollback-Plan?
Merksatz:
Fehler nach Änderung:
Änderung zuerst prüfen.
Systematische Fehlersuche
Eine gute Reihenfolge:
1. Fehler genau beschreiben
2. Zeitpunkt feststellen
3. betroffene Systeme eingrenzen
4. letzte Änderungen prüfen
5. Status prüfen
6. Logs prüfen
7. Ressourcen prüfen
8. Netzwerk prüfen
9. Berechtigungen prüfen
10. Maßnahme testen und dokumentieren
Merksatz:
Nicht raten,
sondern eingrenzen.
Einzelnes System oder viele Systeme?
Wichtige Eingrenzung:
| Betroffen | Wahrscheinliche Richtung |
|---|---|
| ein Benutzer | Benutzerrechte, Client, Konto |
| alle Benutzer | Dienst, Server, Netzwerk, Authentifizierung |
| ein Server | Dienst, Ressourcen, lokale Konfiguration |
| alle Server | Netzwerk, DNS, zentrale Dienste |
| eine Anwendung | Anwendung, Datenbank, Backend |
| mehrere Anwendungen | Infrastruktur, DNS, Storage, Netzwerk |
Merksatz:
Anzahl der Betroffenen hilft bei der Eingrenzung.
Typische Linux-Fehlerbilder
| Fehlerbild | Wahrscheinliche Ursache |
|---|---|
| Dienst startet nicht | Konfiguration, Rechte, Port, Abhängigkeit |
| Permission denied | Rechteproblem |
| No such file or directory | falscher Pfad oder Datei fehlt |
| No space left on device | Speicherplatz oder Inodes voll |
| Read-only file system | Dateisystem nur lesbar oder Fehler |
| Connection refused | Dienst läuft nicht oder Port geschlossen |
| Connection timed out | Firewall, Routing oder Ziel nicht erreichbar |
| Name or service not known | DNS oder Name falsch |
| Too many open files | Limit für offene Dateien erreicht |
| Out of memory | RAM knapp, OOM-Killer aktiv |
| Target is busy | Mount oder Datei wird noch verwendet |
Connection refused
Bedeutung:
Das Zielsystem ist erreichbar,
aber der Dienst nimmt auf diesem Port keine Verbindung an.
Mögliche Ursachen:
Dienst läuft nicht
falscher Port
Dienst lauscht nur auf anderer Adresse
lokale Firewall lehnt aktiv ab
Prüfen:
systemctl status dienst
ss -tulpen
journalctl -u dienst
Merksatz:
Connection refused:
Ziel erreichbar,
Dienst oder Port problematisch.
Connection timed out
Bedeutung:
Die Verbindung erhält keine Antwort innerhalb der Zeit.
Mögliche Ursachen:
Firewall verwirft Pakete
Routingproblem
Ziel nicht erreichbar
falsche IP
Netzwerkproblem
Cloud Security Group blockiert
Prüfen:
ping
ip route
Firewall-Regeln
Netzwerkpfad
Merksatz:
Timeout deutet oft auf Firewall,
Routing
oder Nichterreichbarkeit hin.
Permission denied
Bedeutung:
Zugriff verweigert.
Mögliche Ursachen:
fehlende Dateirechte
falscher Besitzer
falsche Gruppe
fehlendes x-Recht auf Verzeichnis
sudo nötig
Dienstbenutzer hat keine Rechte
Prüfen:
whoami
id
ls -l datei
ls -ld verzeichnis
Merksatz:
Permission denied ist meist ein Rechteproblem.
No such file or directory
Bedeutung:
Datei oder Verzeichnis existiert nicht.
Mögliche Ursachen:
falscher Pfad
Tippfehler
falsche Groß-/Kleinschreibung
Datei wurde gelöscht
Mount fehlt
relativer Pfad falsch verstanden
Prüfen:
pwd
ls -la
find
mount
Merksatz:
Linux unterscheidet Groß-
und Kleinschreibung.
Too many open files
Bedeutung:
Ein Prozess oder Benutzer hat zu viele Dateien,
Sockets
oder Verbindungen geöffnet.
Mögliche Ursachen:
hohe Last
Fehler in Anwendung
zu niedriges Limit
Verbindungsleck
Prüfen:
Logs
Prozessstatus
Limits
offene Dateien
Merksatz:
Unter Linux zählen auch Netzwerkverbindungen als offene Dateien.
Logs und Sicherheit
Logs sind auch für Sicherheit wichtig.
Wichtige Ereignisse:
fehlgeschlagene Logins
sudo-Nutzung
SSH-Zugriffe
neue Benutzer
Rechteänderungen
Dienststarts
Firewall-Blockierungen
ungewöhnliche Prozesse
viele Anmeldeversuche
Beispiele:
journalctl -u ssh
grep -i "failed" /var/log/auth.log
grep -i "sudo" /var/log/auth.log
Merksatz:
Sicherheitsanalyse beginnt oft in Auth-
und Dienstlogs.
Backup und Logs
Logs können nach einem Vorfall wichtig sein.
Aber:
Logs auf demselben kompromittierten System können manipuliert werden.
Besser:
zentrale Logsammlung
SIEM
manipulationsgeschützte Logs
Zeitserver verwenden
ausreichende Aufbewahrung
Merksatz:
Für Sicherheitsvorfälle sind zentrale und geschützte Logs wertvoll.
Zeit und Logs
Korrekte Uhrzeit ist für Logs wichtig.
Wenn die Systemzeit falsch ist, werden Ereignisse schwer nachvollziehbar.
Prüfen:
timedatectl
Zeitdienst prüfen:
systemctl status systemd-timesyncd
oder je nach System:
chrony
ntpd
Merksatz:
Ohne korrekte Zeit sind Logs schwer auswertbar.
Dokumentation bei Fehlersuche
Bei Fehlersuche dokumentieren:
- Fehlerbild
- Zeitpunkt
- betroffene Systeme
- ausgeführte Prüfungen
- relevante Logmeldungen
- Ursache
- Maßnahme
- Ergebnis
- offene Punkte
Warum?
Nachvollziehbarkeit
Wiederverwendbarkeit
Übergabe an Kollegen
spätere Analyse
Prüfungsrelevanz
Merksatz:
Gute Administration dokumentiert Fehler und Lösung.
Typische Befehle dieser Seite
| Befehl | Zweck |
|---|---|
| journalctl | systemd-Journal anzeigen |
| journalctl -u dienst | Logs eines Dienstes anzeigen |
| journalctl -f | Logs live mitlesen |
| journalctl -b | Logs seit letztem Boot |
| dmesg | Kernelmeldungen anzeigen |
| dmesg -T | Kernelmeldungen mit lesbarer Zeit |
| less logfile | lange Logdatei lesen |
| tail -f logfile | Log live verfolgen |
| grep muster logfile | Log nach Muster filtern |
| systemctl status dienst | Dienststatus prüfen |
| top | Prozesse und Last live prüfen |
| free -h | RAM und Swap prüfen |
| df -h | Speicherplatz prüfen |
| df -i | Inodes prüfen |
| du -sh ordner | Ordnergröße prüfen |
| ip addr | IP-Adressen prüfen |
| ip route | Routing prüfen |
| ss -tulpen | Ports prüfen |
| curl -I URL | Webantwort prüfen |
| timedatectl | Uhrzeit und Zeitsynchronisation prüfen |
Typische Prüfungsfragen
| Frage | Kurzantwort |
|---|---|
| Was sind Logs? | Protokolle von Ereignissen |
| Wo liegen viele klassische Logs? | /var/log |
| Was macht journalctl? | systemd-Journal anzeigen |
| Wie zeigt man Dienstlogs? | journalctl -u dienst |
| Wie liest man Logs live mit? | tail -f oder journalctl -f |
| Was macht dmesg? | Kernelmeldungen anzeigen |
| Was ist Monitoring? | regelmäßige Überwachung |
| Was ist Alerting? | Benachrichtigung bei Ereignissen |
| Warum ist Logrotation wichtig? | verhindert zu große Logs |
| Was prüft df -h? | Speicherplatz |
| Was prüft free -h? | RAM und Swap |
| Was bedeutet Connection refused? | Ziel erreichbar, Dienst/Port lehnt ab |
| Was bedeutet Connection timed out? | keine Antwort, oft Firewall/Routing |
| Warum ist korrekte Zeit wichtig? | Logs müssen zeitlich stimmen |
Typische Prüfungsfallen
| Falle | Richtig denken |
|---|---|
| Logs ignorieren | Logs liefern Ursache und Zeitbezug |
| nur Dienst neu starten | erst Status und Logs prüfen |
| cat für riesige Logs nutzen | less, tail oder grep verwenden |
| Monitoring mit Logging verwechseln | Logs protokollieren, Monitoring überwacht |
| Alerting vergessen | Monitoring ohne Alarm wird leicht übersehen |
| hohe CPU ohne Prozessbezug nennen | verursachenden Prozess ermitteln |
| Speicher frei, aber Fehler beim Schreiben | Inodes prüfen |
| Zeitfehler ignorieren | falsche Zeit erschwert Loganalyse |
| Connection refused und timed out gleichsetzen | unterschiedliche Ursachen |
| nach Änderung nicht an Rollback denken | Änderungen dokumentieren und absichern |
IHK-sichere Kurzformulierung
Logs sind Protokolle von Ereignissen und dienen der Fehlersuche, Überwachung und Sicherheitsanalyse. Viele klassische Logdateien liegen unter /var/log, während auf systemd-Systemen journalctl das zentrale Journal auswertet. Dienstprobleme werden typischerweise mit systemctl status und journalctl -u geprüft. tail -f oder journalctl -f können neue Logeinträge live anzeigen. Monitoring überwacht Ressourcen und Dienste wie CPU, RAM, Speicherplatz, Inodes, Netzwerk, Ports, Backups und Zertifikate. Alerting benachrichtigt bei Grenzwerten oder Fehlern. Eine systematische Fehlersuche grenzt das Problem anhand von Fehlerbild, Zeitpunkt, betroffenen Systemen, Logs, Ressourcen, Netzwerk, Rechten und letzten Änderungen ein.
Merksätze
Logs zeigen Ereignisse.
Monitoring überwacht Zustände.
Alerting warnt aktiv.
/var/log enthält viele klassische Logs.
journalctl liest das systemd-Journal.
journalctl -u zeigt Dienstlogs.
journalctl -f liest live mit.
journalctl -b zeigt Logs seit letztem Boot.
dmesg zeigt Kernelmeldungen.
less ist gut für lange Logs.
tail -f liest Logdateien live mit.
grep filtert relevante Logzeilen.
Logrotation verhindert zu große Logs.
df -h prüft Speicherplatz.
df -i prüft Inodes.
free -h prüft RAM und Swap.
top zeigt Last und Prozesse.
ss zeigt Ports.
curl prüft HTTP oder HTTPS.
systemctl status zeigt Dienstzustand.
Connection refused:
Dienst oder Port problematisch.
Connection timed out:
Firewall,
Routing
oder Nichterreichbarkeit.
Permission denied:
Rechteproblem.
No space left on device:
Speicherplatz oder Inodes prüfen.
Nach Änderung zuerst Änderung prüfen.
Nicht raten,
sondern eingrenzen.
Gute Fehlersuche wird dokumentiert.
Korrekte Uhrzeit ist wichtig für Logs.