Ein Server ist eine Aufgabe, keine besondere Linux-Art.
Ein Linux-Server stellt Dienste bereit: Webseiten, Dateien, Datenbanken oder eine Schnittstelle für lokale KI-Modelle. Häufig läuft er ohne grafische Oberfläche und wird über SSH verwaltet. Der entscheidende Unterschied zum Desktop liegt im Betrieb: Andere Menschen oder Programme verlassen sich auf seine Erreichbarkeit, Daten und Sicherheit. Ein funktionierender Start ist deshalb erst der Anfang.
Dieser Artikel setzt Terminal und Dateisystem sowie Benutzerrechte und SSH voraus. Die Beispiele beziehen sich auf Linux mit systemd, GNU-Werkzeugen und iproute2, wie bei Ubuntu Server und Debian. Unit-Namen, Paketstände und Netzwerkkonfiguration unterscheiden sich je nach Installation. Alle Ausgaben des Fehlerfalls sind simulierte Beispielausgaben; hier wird kein echter Server verändert.
Vom Einschalten zum Dienst.
Vereinfacht initialisiert die Firmware die Hardware und startet einen Bootloader. Dieser lädt den Linux-Kernel und gegebenenfalls eine initiale RAM-Disk, die unter anderem den Zugriff auf das eigentliche Root-Dateisystem vorbereitet. Anschließend übernimmt das Init-System. Auf den hier betrachteten Distributionen ist systemd der Systemmanager mit Prozess-ID 1.
Eine Unit beschreibt ein verwaltetes Objekt. .service steht für einen Dienst, .socket für einen aktivierenden Socket, .timer für einen Zeitplan und .mount für einen Mountpunkt. Ein .target bündelt Units zu einem Betriebsziel. „Nach dem Netzwerk starten“ und „nur bei funktionierender Gegenstelle starten“ sind verschiedene Anforderungen. Eine Anwendung muss Ausfälle und verzögerte Bereitschaft selbst sinnvoll behandeln.
Laufzustand und Start beim Booten getrennt prüfen.
Unsere gedachte, bereits eingerichtete Test-VM besitzt demo-web.service. Dieser frei gewählte Unit-Name existiert auf einem normalen System nicht automatisch. Die erste Frage lautet: Was ist gerade passiert?
systemctl status demo-web.service --no-pager
systemctl is-enabled demo-web.service
journalctl -u demo-web.service -b -n 50 --no-pagerstatus zeigt Laufzustand, Hauptprozess und einen kurzen Logausschnitt. failed kann dabei einen von null verschiedenen Rückgabecode verursachen: Das ist eine Information über den Dienst. is-enabled prüft die Einbindung für Aktivierung, nicht die aktuelle Erreichbarkeit. journalctl -u filtert nach Unit, -b nach aktuellem Boot und -n 50 auf die letzten 50 Einträge. Fehlende Logs können auf fehlende Leserechte, Aufbewahrung oder eine andere Logdatei zurückgehen. Persistente Journale sind nicht auf jeder Installation eingerichtet.
| Aktion | Wirkung |
|---|---|
start | Startet eine inaktive Unit jetzt; ein bereits laufender Dienst wird dadurch nicht neu gestartet. |
stop | Beendet den Dienst jetzt; bestehende Verbindungen können abbrechen. |
restart | Stoppt und startet; startet auch eine zuvor inaktive Unit. Unterbricht gegebenenfalls Anfragen. |
enable | Richtet die in der Unit vorgesehenen Aktivierungsverknüpfungen ein; startet ohne --now nicht sofort. |
disable | Entfernt diese Aktivierungsverknüpfungen; stoppt ohne --now nicht. Abhängigkeiten, Timer oder Sockets können weiter aktivieren. |
# Nur in der eigenen, vorbereiteten Test-VM:
sudo systemctl start demo-web.service
# Nach einer gezielten, geprüften Korrektur:
sudo systemctl restart demo-web.serviceDiese beiden Zeilen sind alternative Handlungen an unterschiedlichen Stellen, kein pauschal abzuarbeitendes Reparaturskript. sudo ist hier begründet, weil ein Systemdienst verändert wird. Für Statusabfragen ist es normalerweise nicht erforderlich. Ein reload würde, soweit der Dienst es unterstützt, Konfiguration ohne vollständigen Neustart neu laden; es ist kein überall verfügbares Synonym für restart.
Ressourcen als Verlauf lesen.
Eine hohe Auslastung ist zunächst eine Beobachtung. Mit top siehst du Prozesse, CPU-Zeiten und Veränderungen; mit ps -eo pid,comm,%cpu,%mem --sort=-%cpu erhältst du eine Momentaufnahme mit CPU-Nutzungswerten, die sich auf die Prozesslaufzeit beziehen. Der Load Average zählt auch bestimmte wartende Aufgaben und ist keine CPU-Prozentzahl. Prüfe CPU-Kerne, I/O-Wartezeiten und Dauer, bevor du einen Engpass benennst. Ein einzelner ausgelasteter Thread kann einen Dienst begrenzen, obwohl andere Kerne frei sind.
free -h
df -h / /var
df -i / /varfree -h zeigt RAM und Swap in lesbaren Einheiten. Wenig völlig freier RAM ist wegen Dateicaches normal. Die Spalte available schätzt, wie viel ohne Swapping für neue Anwendungen verfügbar wäre. Belegter Swap allein beweist keinen aktuellen Engpass; anhaltender Speicherdruck und häufiges Ein- und Auslagern sind entscheidender. Auch ein Container kann an seinem eigenen Limit scheitern, während der Host RAM frei hat.
df -h prüft freie Datenblöcke des Dateisystems, auf dem der jeweilige Pfad liegt. df -i prüft die Inode-Belegung: Metadatenplätze für Dateien können bei sehr vielen kleinen Dateien knapp werden, obwohl noch Datenblöcke frei sind. Die Aussage hängt vom Dateisystem ab. Bei „No space left on device“ gehören außerdem Quotas, der tatsächliche Mountpunkt und gegebenenfalls ein Thin-Pool zur Untersuchung. du -sh /var/log schätzt den Platz belegender Dateien in diesem Verzeichnis; gelöschte, noch offene Dateien oder andere Dateisysteme können Abweichungen zu df erklären. Nicht ungeprüft Logs löschen: Sie können Ursache und Zeitverlauf belegen.
Adresse, Weg, Name und Anwendung einzeln testen.
ip addr
ip route
ss -tulpen
ping -c 3 127.0.0.1
dig example.com A
curl --noproxy '*' --connect-timeout 2 --max-time 5 \
-v http://127.0.0.1:8080/ip addr zeigt Interfaces und Adressen, ip route standardmäßig die IPv4-Routen. Für IPv6 ergänzt du -6. Eine Adresse mit Präfix muss zum vorgesehenen Netz passen; eine Default-Route gilt nur, wenn keine spezifischere Route greift. Die konkrete dauerhafte Konfiguration hängt etwa von Netplan, NetworkManager oder systemd-networkd ab. Änderungen an der SSH-Verbindung oder Route brauchen einen gesicherten Rückweg und sind kein Diagnoseschritt dieses Beispiels.
Bei ss -tulpen bedeutet t TCP, u UDP, l lauschende beziehungsweise empfangsbereite Sockets, p Prozessinformationen, e erweiterte Angaben und n numerische Adressen/Ports. Prozessdetails fremder Prozesse können erhöhte Rechte benötigen. 127.0.0.1:8080 ist nur lokal erreichbar; 0.0.0.0:8080 bindet an alle lokalen IPv4-Adressen. Keine dieser Anzeigen beweist, dass Firewalls den Zugriff erlauben. IPv6-Bindings müssen gesondert betrachtet werden.
Der begrenzte ping an Loopback prüft hier nur den lokalen IP-Stack. Ein bewusst gewähltes Gateway im eigenen Lab wäre der nächste ICMP-Test. Ausbleibende Antworten beweisen wegen möglicher ICMP-Filter keinen Hostausfall; erfolgreiche Antworten beweisen keinen offenen HTTP-Port. dig example.com A fragt DNS ab, sofern das zusätzliche Werkzeug installiert ist; es kann eine externe Anfrage senden. getent ahosts example.com ist eine häufig vorhandene Alternative für die Namensauflösung über die Systemkonfiguration einschließlich etwa /etc/hosts. Beide Wege sind deshalb nicht identisch.
curl sendet im Beispiel eine HTTP-GET-Anfrage an einen eigenen lokalen Testdienst. --noproxy '*' umgeht dafür konfigurierte Proxys, die Zeitlimits verhindern langes Warten und -v zeigt Verbindung und Header. Eine HTTP-Antwort wie 503 ist ein anderer Befund als „Connection refused“. Ohne --fail kann curl bei HTTP-Fehlercodes trotzdem erfolgreich enden. Bei HTTPS zusätzlich Zertifikat, Servernamen und Uhrzeit prüfen; eine nackte IP kann ein anderes Zertifikat oder einen anderen virtuellen Host ansprechen. TLS-Prüfungen nicht reflexartig abschalten.
Vom Netzwerkproblem zur belegten Ursache.
Notiere zuerst Zeitpunkt, Client, Zielname, IP, Port und genaue Fehlermeldung. „Die Website geht nicht“ ist zu ungenau. Die folgende Prüfkette beginnt auf dem Server; ein parallel durchgeführter Clienttest zeigt, ab welcher Strecke sich die Ergebnisse unterscheiden.
Fall: Der Test-Webservice startet nicht.
Die Test-VM soll ausschließlich lokal auf Port 8080 antworten. Wir lesen Status, zeitlich passende Logs und den Listener desselben Ports:
systemctl status demo-web.service --no-pager
journalctl -u demo-web.service -b -n 50 --no-pager
ss -ltnp 'sport = :8080'Simulierte Beispielausgaben, gekürzt und redaktionell vereinfacht:
Active: failed (Result: exit-code)
demo-web: bind 127.0.0.1:8080: Address already in use
LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(("lab-alt",pid=4210,fd=3))Beobachtung: Die Unit scheitert, das Log nennt einen Bindefehler, und ein anderer Prozess belegt den erwarteten Listener. Hypothese: Ein zweiter Labdienst verwendet dieselbe Adresse und denselben TCP-Port. Noch ist nicht bewiesen, ob dieser Prozess entbehrlich ist oder die Konfiguration des neuen Dienstes falsch ist.
In der eigenen Test-VM ließe sich mit ps -p 4210 -o pid,comm,args und systemctl status 4210 --no-pager prüfen, welcher bekannte Prozess beziehungsweise welche Unit dazugehört. Die PID ist nur die simulierte Momentaufnahme und darf nicht blind übernommen werden. Gleiche Prozessidentität, Portkonfiguration und Logzeit ab. Erst dann steht die Diagnose Adress-/Portkonflikt fest; DNS und die externe Firewall erklären diesen lokalen Bindefehler nicht.
Die Korrektur ist eine bewusste Entscheidung: den nachweislich überflüssigen Testdienst geordnet beenden oder einen für die Testanwendung vorgesehenen freien Port konfigurieren. Kein pauschales Töten unbekannter Prozesse. Danach gezielt starten und dieselben drei Prüfungen sowie den lokalen curl-Aufruf wiederholen. Erst „active“, der richtige Listener und die erwartete HTTP-Antwort belegen die Wiederherstellung. Diese Korrektur und Wiederholungsprüfung sind hier beschrieben, nicht ausgeführt.
Betrieb heißt auch: morgen wiederherstellen können.
Updates brauchen verlässliche Paketquellen, aktuelle Paketlisten und ein Wartungsfenster. Bei Ubuntu/Debian lädt apt update Paketinformationen; apt upgrade aktualisiert installierte Pakete nach den Regeln des Paketmanagers. Beides sind administrative Änderungen, keine Reparatur für jedes Erreichbarkeitsproblem. Vor Änderungen Releasehinweise, Sicherung und mögliche Dienstneustarts prüfen. Major-Upgrades benötigen einen eigenen Plan. Automatische Sicherheitsupdates können helfen, müssen aber hinsichtlich Reboots und Ausnahmen bewusst konfiguriert und überwacht werden.
Nutze getrennte Dienstkonten mit notwendigen Rechten, SSH-Schlüssel und kontrollierte Administrationszugänge. Begrenze offene Ports und Managementzugänge; prüfe nach Updates, ob vorgesehene Dienste weiter erreichbar sind. Ein Log voller fehlgeschlagener Anmeldungen ist Anlass für eine eingegrenzte Untersuchung, nicht für das ungeprüfte Löschen von Benutzern oder Firewallregeln. Uhrzeitsynchronisation hilft, Ereignisse zwischen Systemen zeitlich zuzuordnen.
Ein Snapshot hält einen Zustand eines Volumes oder einer VM für einen schnellen Rücksprung fest. Liegt er auf demselben defekten oder kompromittierten Speichersystem, hilft er unter Umständen nicht. Ein Backup ist eine separat aufbewahrte, wiederherstellbare Sicherung. Zum Plan gehören Konfiguration, Nutzdaten, notwendige Schlüssel unter geeignetem Schutz, Aufbewahrung und ein regelmäßig geprobter Restore. Datenbanken können anwendungskonsistente Sicherungen oder zusätzliche Dumps benötigen; eine Dateikopie während Schreibvorgängen reicht nicht immer.
Monitoring verbindet Ressourcenverlauf, freien Platz und Inodes, Unit-Fehler, Backup-Ergebnis und tatsächliche Dienstbereitschaft. Ein grüner Prozessstatus genügt nicht: Eine synthetische HTTP-Prüfung sollte die erwartete Antwort prüfen. Lege fest, wer welche Meldung bearbeitet, wie lange Datenverlust tolerierbar ist und wie schnell ein Restore gelingen muss. Für Betrieb in Gästen führt der Lernpfad weiter zu Virtualisierung mit Proxmox VE.
Zwei Befunde selbst einordnen.
Eine Unit ist enabled, aber inactive. Bedeutet das, dass der Dienst gerade Anfragen beantwortet? Welcher nächste Schritt liefert einen Beleg?
Lösung: Aktivierung ist kein Erreichbarkeitstest
Nein. „Enabled“ beschreibt Aktivierungsverknüpfungen. Prüfe systemctl status und passende Logs; je nach Unit kann Inaktivität sogar vorgesehen sein. Für einen dauerhaften Webdienst folgen Listener und gezielter HTTP-Test. Ein Neustart ohne diese Prüfung würde Belege verwischen und könnte unnötig unterbrechen.
Eine Anwendung kann keine neue Datei anlegen. df -h /var zeigt viel freien Platz, df -i /var dagegen 100 Prozent Belegung. Welche Erklärung ist naheliegend, und was ist noch zu klären?
Lösung: Freie Bytes sind nur eine Grenze
Für das betreffende Dateisystem fehlen wahrscheinlich freie Inodes. Viele kleine Dateien können diese Grenze erreichen. Prüfe, ob die fehlschlagende Datei tatsächlich auf diesem Dateisystem liegt und ob weitere Grenzen wie Quotas mitwirken. Ermittle den verursachenden Pfad und seine Aufbewahrungsregeln. Erst eine abgestimmte Bereinigung oder Kapazitätsänderung ist eine Korrektur; pauschales Löschen wäre keine Diagnose.
Quellen und fachlicher Stand.
Geprüft am . Stabile Grundbefehle für systemd-basierte Linux-Systeme; online geprüfte systemd-Dokumentation: Version 262. Die installierten Distributionen können ältere Versionen liefern.
- systemd: Bootablauf, systemctl und journalctl: Units, Laufzustand, Aktivierung und Logs.
- Debian: free, df und Linux-Kernel: Speicherverwaltung.
- ip address, ip route, ss und ping: Linux-Netzwerkdiagnose.
- ISC BIND: dig und curl-Handbuch: Name, Verbindung und HTTP getrennt betrachten.
- Ubuntu Server: Paketverwaltung und Serverdokumentation als betriebsspezifische Vertiefung.