Thema: kernel
-
Prüfen, ob ein Linux-Host nach Updates einen Neustart oder einen Dienstneustart benötigt
Debian und Ubuntu kennzeichnen einen ausstehenden Neustart mit der einfachen Datei /var/run/reboot-required. Bei Systemen der RHEL-Familie muss dagegen der laufende Kernel mit dem neuesten installierten verglichen oder eine Prüfung im Stil von needs-restarting ausgeführt werden; keine der beiden Familien weist auf der Shell automatisch darauf hin.
-
Installierte Kernel unter Debian und Ubuntu verwalten: Aufräumen, Platz in /boot, HWE und Livepatch
Alte Kernel-Pakete sammeln sich in /boot an, bis apt autoremove sie entfernt. Ubuntu bietet zusätzlich einen fortlaufend aktualisierten Hardware-Enablement-Kernel (HWE) für LTS-Releases und Canonicals Livepatch-Dienst, der Kernel-Sicherheitskorrekturen ohne sofortigen Neustart einspielt – beides gibt es nur unter Ubuntu, nicht unter Debian.
-
Kernel-Panics und Absturzdaten unter Linux: Journal des vorherigen Boots, pstore und netconsole
Nach einem Linux-Kernel-Panic und Neustart liest `journalctl -b -1 -k` die Kernel-Meldungen des vorherigen Boots, sofern das Journal persistent war. pstore (etwa ramoops, wo konfiguriert) bewahrt einen Panic-Eintrag über den Neustart hinweg auf, auch wenn das Journal nicht erhalten blieb; netconsole sendet Kernel-Meldungen in Echtzeit über das Netzwerk an einen anderen Rechner. kdump erstellt einen vollständigen Speicherabzug und wird an anderer Stelle behandelt.
-
kdump konfigurieren, um einen Kernel-Crash unter RHEL aufzuzeichnen
kdump reserviert vorab Speicher, damit nach einer Kernel-Panic ein zweiter, minimaler Kernel starten und ein vmcore zur Analyse schreiben kann. Die Methodik beschreibt, wie der Speicher reserviert und der Dienst aktiviert wird und warum ein gezielter Test den Host abstürzen lässt – der Test ist entsprechend einzuplanen.
-
Kernel-Parameter unter Linux mit sysctl setzen: Änderungen zur Laufzeit versus /etc/sysctl.d
sysctl -w ändert einen Kernel-Parameter nur bis zum nächsten Neustart; für eine dauerhafte Änderung gehört eine Datei in /etc/sysctl.d/, und die Ladereihenfolge über /usr/lib, /etc und /run muss bekannt sein. sysctl --system wendet alle konfigurierten Dateien an und zeigt bei Konflikten, welche Datei sich durchsetzt.
Maschinenlesbar: JSON