Linux Kernel 6.x: Relevante Neuerungen für Hosting-Server

Kernelstand richtig einordnen

Die Bezeichnung Linux 6.x fasst viele Hauptreleases zusammen, nicht einen einheitlichen Funktionsstand. Als Mainline gilt die von Linus Torvalds gepflegte Hauptlinie: Nach dem Merge Window folgen üblicherweise Release Candidates bis zum finalen Hauptrelease. Davon zu unterscheiden sind Stable- und LTS-Zweige, die veröffentlichte Kernel mit ausgewählten Korrekturen weiterpflegen. Distributionskernel folgen wiederum eigenen Paketständen, Supportzusagen und Integrationsentscheidungen.

Gerade für Hosting-Server sind Backports entscheidend: Eine Distribution kann einzelne Funktionen, Treiberverbesserungen oder Sicherheitskorrekturen in einen älteren, langfristig gepflegten Kernel übernehmen. Umgekehrt kann sie Funktionen deaktivieren, Patches abwandeln oder durch Konfiguration begrenzen. Aus einer Versionsnummer lässt sich daher weder ein vollständiger Funktionsumfang noch die konkrete Betriebswirkung ableiten.

Der Befehl uname -r identifiziert den laufenden Release-String und ist ein sinnvoller Startpunkt für Inventur und Paketabgleich. Er beweist aber nicht, dass eine Funktion einkompiliert, zur Laufzeit aktiviert oder für eine Anwendung erreichbar ist. Auch ein neuer Kernelstand ersetzt keine Prüfung der vom Distributor bereitgestellten Konfiguration und Dokumentation.

Für eine belastbare Einordnung prüfst du mehrere Ebenen: Distribution und Paketstand, Kernel-Konfiguration, Boot-Parameter und vorhandene Laufzeitschnittstellen. Hinzu kommen Hardware, Firmware und Treiber, etwa bei Storage oder Virtualisierung. Schließlich muss die eingesetzte Anwendung eine Schnittstelle tatsächlich nutzen; eine vorhandene Kernel-Funktion verändert einen Webserver nicht automatisch.

Dieser Artikel folgt deshalb keiner vollständigen Releasechronik. Er betrachtet Funktionen, die für den Betrieb heutiger 6.x-Kernel relevant sind. Nicht jede davon wurde erst in der 6.x-Reihe eingeführt; entscheidend sind der im konkreten Kernel verfügbare Funktionsstand, mögliche Erweiterungen und die Auswirkungen auf Speicherverhalten, CPU-Konkurrenz, Prozessisolation und Wartung.

Vier Betriebsbereiche für Hosting

Für Hosting-Server sind vier Betriebsbereiche besonders relevant: Speicherdruck, CPU-Konkurrenz, zusätzliche Prozessisolation und Wartung. Dabei geht es nicht um möglichst viele aktivierte Kernel-Funktionen, sondern um passende Werkzeuge für ein beobachtetes Problem. PHP-FPM-Pools, Datenbanken, Caches, Batch-Jobs und spezialisierte Worker stellen unterschiedliche Anforderungen, die sich nicht aus der Kernelversion allein ableiten lassen.

cgroup v2 ist dabei ein Querschnittsthema, aber keine Neuerung der 6.x-Reihe. Die Hierarchie strukturiert Speicher- und CPU-Ressourcen für Dienste, Container oder Kundengruppen. Welche Controller verfügbar und in einer Unterhierarchie aktiviert sind, muss am jeweiligen cgroup-v2-Mount geprüft werden. Ein dedizierter Webserver benötigt deshalb eine andere Bewertung als ein Container- oder VM-Host.

Die Tabelle trennt bewusst Build-Konfiguration, Boot-Aktivierung, Laufzeitschnittstelle und tatsächliche Nutzung. Eine Funktion kann im Kernel enthalten, aber deaktiviert oder für die Anwendung bedeutungslos sein. Ebenso können Distributionen Funktionen zurückportieren. Bewerte Änderungen daher anhand von Lastverlauf, cgroup-Aufbau, Hardware und Anwendungsmesswerten statt anhand der höchsten verfügbaren Versionsnummer.

Speicherdruck und Page Reclaim

Linux verwendet freien Arbeitsspeicher gern als Dateicache. Viel belegter RAM ist deshalb für sich genommen kein Fehler und auch kein Beleg für Speicherverschwendung: Zwischengespeicherte Dateiseiten können bei Bedarf zurückgewonnen werden. Für die Diagnose zählen eher Entwicklung und Folgen der Last, etwa Antwortzeiten, Swap-Aktivität, Fehlerprotokolle und Abbrüche von Prozessen.

Unter Speicherdruck entscheidet Page Reclaim , welche Seiten aus Cache entfernt oder gegebenenfalls ausgelagert werden können. Der Kernel kann diese Arbeit asynchron über kswapd erledigen. Muss ein Prozess bei einer Speicheranforderung selbst Seiten zurückgewinnen, spricht die Kernel-Dokumentation von direktem Reclaim; dieser kann die anfordernde Arbeit und damit beobachtete Latenzen beeinträchtigen.

Warnsignale entstehen meist als Kombination: anhaltende Swap-Ein- oder -Auslagerung, OOM-Ereignisse, wachsende Wartezeiten und Fehler auf Anwendungsebene verdienen eine gemeinsame Zeitachse. Ein einmaliger Ausschlag kann dagegen ein geplanter Batch-Job sein. Auch ein Cache-Dienst mit hohem RAM-Anteil ist nicht automatisch Ursache, wenn seine cgroup und die übrigen Prozesse ausreichend handlungsfähig bleiben.

cgroup v2 ergänzt die globale Sicht um Dienst- oder Containergrenzen. Der Speichercontroller stellt Ereigniszähler bereit; memory.events ist hierarchisch, während memory.events.local nur lokale Ereignisse der jeweiligen cgroup ausweist. Damit lässt sich unterscheiden, ob ein Problem am eigenen Dienstlimit oder an Belastung in einer übergeordneten Struktur beteiligt ist.

Diese Grundlagen sprechen noch nicht für Tuning. Bevor du Limits, Swap-Strategie oder Kernel-Schnittstellen veränderst, ordnest du Lastverursacher, cgroup-Zuordnung und zeitliche Korrelation ein. Besonders ein hartes Speicherlimit kann einen Dienst früher scheitern lassen, statt die zugrunde liegende Arbeitsspitze zu lösen. Erst die Diagnose zeigt, ob eine Änderung überhaupt eine passende technische Stellschraube hat.

Multi-Gen LRU gezielt prüfen

Multi-Gen LRU ist eine alternative Implementierung für Page Reclaim und ist in der hier behandelten Kernel-Dokumentation ab Linux 6.1 beschrieben. Unter Speicherdruck muss der Kernel entscheiden, welche Dateicache- oder anonymen Speicherseiten zurückgewonnen werden können. Multi-Gen LRU ordnet Seiten dafür Generationen nach Zugriffsalter zu und berücksichtigt Zugriffsmuster, damit weniger wahrscheinlich häufig benötigte Seiten für Reclaim ausgewählt werden.

Das ist für einen dicht belegten Webhosting-Server relevant, auf dem PHP-FPM-Pools, eine Datenbank und ein Cache-Dienst gleichzeitig RAM beanspruchen. Die Funktion kann die Auswahl beim Reclaim verändern, ist aber weder eine Speichererweiterung noch eine Zusage für geringere Antwortzeiten. Arbeitsmenge, RAM-Ausstattung, Swap, Massenspeicher und die cgroup-Grenzen der Dienste bestimmen weiterhin, ob und wie sich ein Effekt bemerkbar macht.

Vor jeder Bewertung prüfst du zunächst, ob die Laufzeitschnittstelle vorhanden und lesbar ist. Aktuelle Kernel-Dokumentation nennt dafür die Konfigurationsoptionen CONFIG_LRU_GEN und CONFIG_LRU_GEN_ENABLED sowie den Pfad unter /sys/kernel/mm/lru_gen/. Ein Distributionskernel kann Funktionsstände zurückportieren oder anders konfigurieren; die Versionsnummer allein ist daher kein belastbarer Nachweis.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

Eine Ausgabe weist zunächst nur nach, dass die dokumentierte sysfs-Schnittstelle vorhanden und lesbar ist. Für den Aktivierungszustand ist der Bitwert relevant: 0x0001 ist der Hauptschalter von Multi-Gen LRU. Fehlt dieses Bit, kann die Datei trotz verfügbarer Schnittstelle einen deaktivierten Hauptschalter anzeigen; weitere Bits betreffen zusätzliche Komponenten. Auch ein gesetztes Hauptbit ist keine allgemeine Empfehlung, den Wert auf Produktion zu verändern.

Schreibzugriffe auf sysfs sind deshalb kein Standard-Tuning. Erfasse zuerst Zeitreihen zu Reclaim, Swap, Latenzen und cgroup-Ereignissen, dokumentiere bei einer begründeten Änderung den Ausgangswert und lege einen Rückweg fest. So bleibt nachvollziehbar, ob sich tatsächlich das beobachtete Problem verändert hat oder lediglich mehrere Stellgrößen gleichzeitig verschoben wurden.

Besonders vorsichtig solltest du bei gleichzeitig knappen Speicherlimits und überbuchten Diensten sein. Ein veränderter Reclaim-Algorithmus korrigiert keine zu großen PHP-Worker-Pools, unpassende Datenbank-Caches oder eine fehlende Trennung konkurrierender Kunden. Die sinnvolle Reihenfolge lautet: Ursache und betroffene cgroup bestimmen, Last begrenzen oder verteilen und erst danach eine verfügbare Kernel-Funktion als möglichen Einflussfaktor bewerten.

Speicherprobleme sicher eingrenzen

Belegter RAM ist für sich kein Fehler: Linux nutzt freien Speicher gezielt als Dateicache. Handlungsbedarf entsteht eher, wenn Anforderungen in direkten Reclaim laufen, Swap-Aktivität ansteigt, OOM-Ereignisse auftreten oder Anfragen gleichzeitig langsamer werden. Asynchroner Reclaim durch kswapd arbeitet im Hintergrund; direkter Reclaim geschieht dagegen im Kontext der Speicher anfordernden Aufgabe und kann deren Ausführung verzögern.

Die Ereignisdatei memory.events zählt Ereignisse hierarchisch, also einschließlich untergeordneter cgroups. Für die ausschließlich lokale Sicht steht memory.events.local bereit. high steht für Drosselung und direkten Reclaim nach Überschreiten von memory.high, während oom eine am cgroup-Limit drohende fehlgeschlagene Allokation zählt. oom_kill zählt dagegen Prozesse dieser cgroup, die durch irgendeine Art von OOM-Killer beendet wurden.

Beginne die Diagnose mit einer klaren Zuordnung: Welcher Dienst oder Container gehört zur auffälligen cgroup, wann traten Ereignisse auf, und welche Anwendungssignale gab es zugleich? Vergleiche danach lokale mit hierarchischen Zählern, Systemjournal, Swap-Verlauf sowie HTTP-Latenzen, Datenbank-Wartezeiten oder Fehlerraten. Bei einem OOM-Fall ist zusätzlich zu klären, ob die Daten auf einen cgroup-bezogenen Vorgang oder einen möglichen globalen Speichermangel hindeuten.

Der Wert memory.max ist eine harte cgroup-Grenze und keine erste Standardmaßnahme. Ein engeres Limit kann Mandanten schützen, aber eine Anwendung auch früher in OOM-Situationen bringen; ein höheres Limit kann Verdrängung bei Nachbardiensten verstärken. Prüfe daher zunächst Worker-Zahlen, Cache-Größen, Lastspitzen und die cgroup-Struktur. Ändere anschließend nur eine begründete Stellgröße mit Beobachtungszeitraum und Rückrollplan.

EEVDF und CPU-Konkurrenz verstehen

Die aktuelle offizielle Kernel-Dokumentation ordnet den Beginn des Übergangs zu EEVDF Linux 6.6 zu. Earliest Eligible Virtual Deadline First verändert die Auswahl normaler, fair eingeplanter Tasks: Berücksichtigt werden virtuelle Laufzeit, Lag als Abweichung von der idealen Verteilung und virtuelle Fristen. Berechtigte Tasks mit der frühesten virtuellen Frist können dadurch zuerst CPU-Zeit erhalten.

Die Formulierung „Übergang“ ist wichtig. EEVDF ersetzt die Auswahlentscheidung der Fair-Scheduling-Klasse nicht in dem Sinn, dass damit sämtliche historisch als CFS bezeichneten Datenstrukturen, Schnittstellen und Konzepte verschwinden. Auch die aktuelle Dokumentation vergleicht EEVDF weiterhin mit CFS. Für einen konkreten Distributionskernel muss deshalb dessen integrierter Patch- und Funktionsstand geprüft werden, statt allein von 6.6 oder höher auf ein vollständig einheitliches Verhalten zu schließen.

Für Hosting ist diese Änderung vor allem bei Mischlast relevant. Webanfragen, Datenbankarbeit und Monitoring konkurrieren beispielsweise mit Importen, Komprimierung oder Backups. Ein anderes Latenzprofil zwischen Kernelständen ist möglich, bedeutet aber nicht automatisch mehr Gesamtdurchsatz. Dauerhaft ausgelastete Kerne, blockierte Prozesse, I/O-Wartezeiten und ungeeignete Anwendungskonfigurationen löst der Scheduler nicht.

Die operative Trennung erfolgt weiterhin über Dienst- und Plattformgrenzen. CPU-Gewichte beeinflussen die relative Verteilung bei Konkurrenz, während Quoten die nutzbare Rechenzeit begrenzen können. Wenn latenzkritische Weblast zuverlässig von umfangreichen Batch-Jobs getrennt werden muss, kann auch eine eigene VM oder ein separater Host angemessen sein. EEVDF ersetzt diese Ressourcenplanung nicht.

Vor der Abfrage von cgroup.controllers musst du feststellen, ob und wo cgroup v2 eingehängt ist. Der folgende lesende Ablauf sucht den cgroup-v2-Mountpoint, statt den üblichen Pfad /sys/fs/cgroup vorauszusetzen. Auf einem reinen cgroup-v1-System bleibt die Variable leer; bei einer hybriden Hierarchie zeigt sie nur den gefundenen v2-Mount.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r benennt nur den laufenden Release-String. cgroup.controllers listet die Controller auf, die an genau dieser cgroup zur Aktivierung verfügbar sind; es bestätigt nicht, dass sie in den relevanten Unterhierarchien eingeschaltet wurden. Dafür ist unter anderem cgroup.subtree_control an den jeweiligen Hierarchieebenen zu prüfen. Controller werden top-down freigegeben, sodass eine Kind-cgroup nur vom Elternknoten bereitgestellte Controller weiterreichen kann.

systemd-cgtop liefert ebenfalls nur eine Momentaufnahme und ist keine Ursachenanalyse. Sammle CPU-Auslastung je Dienstgruppe, Request-Latenzen, Laufzeiten der Batch-Jobs und gegebenenfalls I/O-Wartezeiten über mehrere vergleichbare Lastphasen. Treten Verzögerungen nur während eines Backups auf, sind dessen Zeitfenster, CPU-Gewicht oder Quote meist konkretere erste Stellschrauben als vermutetes Scheduler-Tuning.

Landlock für spezialisierte Worker

Landlock wurde erstmals mit Linux 5.13 eingeführt und ist daher keine ursprüngliche Neuerung der 6.x-Reihe. In 6.x-Kerneln stehen je nach Release und Distributionskernel unterschiedliche, erweiterte ABI-Stände zur Verfügung. Die Funktion ist eine ergänzende Sicherheitsmechanik, mit der sich ein Prozess selbst weiter beschränken kann.

Als stapelbares Linux Security Module wirkt Landlock zusätzlich zu den bereits geltenden Zugriffsentscheidungen; es ersetzt weder Unix-Dateirechte noch SELinux, AppArmor, Namespaces oder Container. Regeln können unter anderem Dateisystemzugriffe begrenzen und werden an nachfolgend gestartete Kindprozesse weitergegeben. Der praktische Funktionsumfang hängt von der verfügbaren ABI und der Kernel-Konfiguration ab.

Sinnvoll ist Landlock vor allem für selbst entwickelte oder gezielt ausgewählte Einzelprozesse. Ein Konverter für Kundenuploads könnte Dateien nur aus einem Eingabeordner lesen und Ergebnisse ausschließlich in einen Ausgabeordner schreiben. Selbst wenn der Dienst fehlerhaft verarbeitet wird, soll er weder SSH-Schlüssel noch Anwendungsgeheimnisse oder allgemeine Systempfade lesen können. Diese Begrenzung ergänzt eine sorgfältige Rechtevergabe, sie macht sie nicht entbehrlich.

Eine produktive Regel darf nicht allein von einem aktuellen Kernel ausgehen. Landlock besitzt ABI-Versionen; eine Anwendung sollte die verfügbare ABI zur Laufzeit abfragen und nur Zugriffsrechte oder Funktionen anfordern, die diese ABI unterstützt. Damit kann sie auf älteren Systemen abgestuft arbeiten, statt wegen einer nicht verfügbaren Schnittstelle vollständig auszufallen.

Davon getrennt legt handled_access_fs explizit fest, welche Dateisystemzugriffe ein Ruleset behandelt und ohne passende Regel standardmäßig verweigert. Dieser ausdrückliche Vertrag zwischen Anwendung und Kernel verhindert, dass eine Sandbox allein durch ein Systemupdate unbemerkt strenger wird und dadurch Anwendungen bricht. ABI-Abfrage und explizit behandelte Rechte gehören daher zusammen, lösen aber unterschiedliche Kompatibilitätsaufgaben.

Für den Dateikonverter folgt daraus eine schrittweise Einführung: benötigte Lese-, Schreib- und Arbeitsverzeichnisse aus dem tatsächlichen Ablauf ableiten, Fehlerpfade berücksichtigen und zunächst im Staging prüfen. Eine knappe Beispiel-Policy wäre kein belastbares Produktionsrezept, denn temporäre Dateien, externe Bibliotheken und gestartete Hilfsprogramme können weitere Zugriffe benötigen. Weiterführende Maßnahmen zur Dienstisolation behandelt auch der Beitrag zu Kernel-Hardening für Hosting-Server.

Besondere Vorsicht gilt bei OverlayFS. Regeln für eine Overlay-Schicht beschränken nicht automatisch die zusammengeführte Mount-Hierarchie und umgekehrt. Container- und Build-Umgebungen mit Overlays brauchen deshalb eine eigene Prüfung der konkreten Mounts und Zugriffspfade. Landlock ist dort eine mögliche zusätzliche Schicht, aber keine pauschale Mandantentrennung und kein Ersatz für ein tragfähiges Container- oder Berechtigungskonzept.

DAMON nur für Sonderfälle

DAMON und darauf aufbauende Reclaim-Mechanismen sind nicht pauschal als erstmals mit Linux 6.x eingeführte Funktionen einzuordnen. Für Administratoren zählt der Funktionsstand des konkret eingesetzten 6.x- oder Distributionskernels. DAMON beobachtet Speicherzugriffe mit dem Ziel, Bereiche nach ihrem Nutzungsverhalten einordnen zu können.

Darauf aufbauend versucht DAMON_RECLAIM, lange nicht verwendeten Speicher unter leichtem Druck proaktiv zurückzugewinnen. Das Verfahren ergänzt den normalen LRU-basierten Reclaim; es soll ihn nicht ersetzen. Die Kernel-Dokumentation ordnet es allgemeinen überbuchten Speichersystemen zu und nennt Free-Pages-Reporting-basierte Virtualisierung als Beispiel.

Bei diesem Virtualisierungsszenario ist die Ebene entscheidend: Gäste melden dem Host freie Speicherseiten, die der Host anderen Gästen zuteilen kann. Wenn ein Gast nur wenig freien Speicher meldet, obwohl er lange nicht genutzte Seiten hält, kann proaktiver Reclaim im Gast dazu beitragen, mehr freie Seiten an den Host zu melden. DAMON_RECLAIM ist damit nicht ohne weitere Prüfung eine hostseitige Lösung für ungenutzten Arbeitsspeicher von Gästen.

Für einen einzelnen Web- oder Datenbankserver ist das deshalb keine Standardmaßnahme. Auch in virtualisierten Umgebungen muss zunächst klar sein, auf welcher Ebene der Druck entsteht und ob tatsächlich lange ungenutzte Bereiche die Ursache sind. CPU-Engpässe, langsamer Storage, ungeeignete cgroup-Grenzen oder aktive Anwendungscaches können dieselben Symptome erklären, ohne dass proaktiver Reclaim die passende Antwort wäre.

Quoten, Altersgrenzen und Wassermarken steuern, wann und in welchem Umfang DAMON_RECLAIM arbeitet. Sie sind keine übertragbaren Standardwerte: Eine zu aggressive Auswahl kann nützlichen Dateicache oder wiederkehrend benötigte Speicherseiten vorzeitig verdrängen. Das kann zusätzliche I/O-Vorgänge auslösen und CPU-Zeit für erneute Arbeit beanspruchen, obwohl der nominell freie Speicher steigt.

Eine belastbare Entscheidung verlangt daher Messungen mit klaren Vergleichsgrößen, etwa freiem, vom Gast gemeldetem Speicher, Reclaim-Aktivität, Swap-Verhalten, Storage-Latenz und Anwendungsantwortzeiten. Erprobe Änderungen zuerst in einer vergleichbaren Staging-Umgebung, lege einen Rückweg fest und beobachte sie über repräsentative Lastphasen. Fehlen diese Voraussetzungen oder ist die Ursache des Speicherdrucks ungeklärt, bleibt DAMON bewusst deaktiviert.

Updates, Livepatching und Neustarts

Kernel-Wartung beginnt mit dem Abgleich zwischen Sicherheitsmeldung, installiertem Paket und tatsächlich laufendem Kernel. Prüfe anschließend in den Hinweisen der eigenen Distribution, welche Korrektur für genau diesen Kernelzweig vorgesehen ist und ob ein Neustart verlangt wird. Eine höhere 6.x-Versionsnummer allein belegt weder den enthaltenen Patch noch die Verfügbarkeit eines passenden Livepatches; Sicherheitskorrekturen können auch in ältere Distributionskernel zurückportiert werden.

Auch Livepatching wurde nicht erst mit Linux 6.x als Konzept eingeführt. Die für 6.x-Kernel relevante Infrastruktur erlaubt, bestimmte Kerneländerungen zur Laufzeit einzuspielen. Kumulative Livepatches können dabei einen älteren Patch atomar durch einen neueren ersetzen. Die dokumentierten Grenzen betreffen unter anderem Zustandsänderungen, Callbacks und das Zurückwechseln zwischen Patches.

Ob für einen konkreten Distributionskernel ein geeigneter Livepatch bereitsteht, muss anhand des jeweiligen Angebots und der Freigaben des Anbieters geprüft werden. Aus der allgemeinen Kernel-Infrastruktur folgt weder, dass jede Sicherheitskorrektur live verfügbar ist, noch dass ein eingespielter Patch ein vollständiges Kernel-Update dauerhaft ersetzt. Plane deshalb weiterhin reguläre Wartungsfenster ein.

Bewerte zuerst die Dringlichkeit und Auswirkung eines Updates, gleiche dann Paketstand und laufenden Kernel ab und prüfe das konkrete Livepatch-Angebot. Nach einem regulären Kernel-Update mit Neustart kontrollierst du, ob der erwartete Kernel aktiv ist und die kritischen Dienste, Netzwerkpfade, Sicherungen und das Monitoring korrekt arbeiten. Diese Prüfung gehört zum Wartungsablauf und sollte nicht aus der bloßen Erreichbarkeit des Servers abgeleitet werden.

Ein geplanter Neustart kann trotz Livepatching erforderlich bleiben. Änderungen an Kernel-Boot-Parametern werden typischerweise erst beim nächsten Start wirksam. Bei Treibern, Geräte-Firmware und Hardware hängt das Vorgehen dagegen von der Komponente, ihrer Einbindung und dem Herstellerverfahren ab: Teilweise genügen ein Modul-, Geräte- oder Dienstneustart, in anderen Fällen ist ein vollständiger Host-Neustart nötig.

Der ergänzende Beitrag über Livepatching auf AlmaLinux-Servern behandelt eine konkrete distributionsabhängige Umsetzung. Übertrage solche Abläufe nicht ungeprüft auf andere Kernelzweige oder Anbieter. Maßgeblich sind die Pakete, unterstützten Kernelstände und Betriebshinweise der tatsächlich eingesetzten Plattform.

• Bewusst nichts verändern, wenn die beobachtete Störung noch keine nachvollziehbare Ursache hat.
• Keine Livepatch- oder Kerneländerung ohne passende Staging-Prüfung und dokumentierten Rückweg einplanen.
• Keine Funktion aktivieren, wenn die betroffene Anwendung oder Plattform ihre Schnittstelle nicht nutzt.
• Ein fehlendes Wartungsfenster nicht mit der Annahme ersetzen, Livepatching decke jedes Kernel-Update ab.