Linux-kernel 6.x: relevante vernieuwingen voor hostingservers

De kernelstand correct bepalen

De benaming Linux 6.x omvat vele hoofdreleases, niet één uniform functieniveau. Als mainline geldt de door Linus Torvalds onderhouden hoofdtak: na de merge window volgen doorgaans release candidates tot aan de definitieve hoofdrelease. Hiervan moeten de Stable- en LTS-takken worden onderscheiden, die gepubliceerde kernels met geselecteerde correcties verder onderhouden. Distributiekernels volgen op hun beurt hun eigen pakketversies, ondersteuningsverplichtingen en integratiebeslissingen.

Vooral voor hostingservers zijn Backports Cruciaal: een distributie kan afzonderlijke functies, verbeteringen aan stuurprogramma’s of beveiligingscorrecties overnemen in een oudere kernel die op lange termijn wordt onderhouden. Omgekeerd kan zij functies uitschakelen, patches aanpassen of deze via configuratie beperken. Uit een versienummer kan daarom noch de volledige functionaliteit, noch het concrete effect op de werking worden afgeleid.

Het commando uname -r geeft de huidige releasestring weer en vormt een goed uitgangspunt voor inventarisatie en het vergelijken van pakketten. Het bewijst echter niet dat een functie is ingecompileerd, tijdens de uitvoering is geactiveerd of voor een toepassing toegankelijk is. Ook een nieuwe kernelversie is geen vervanging voor een controle van de door de distributeur verstrekte configuratie en documentatie.

Voor een betrouwbare classificatie controleer je verschillende niveaus: distributie en pakketstatus, kernelconfiguratie, opstartparameters en aanwezige runtime-interfaces. Daarnaast zijn er hardware, firmware en stuurprogramma's, bijvoorbeeld bij opslag of virtualisatie. Ten slotte moet de gebruikte toepassing daadwerkelijk gebruikmaken van een interface; een bestaande kernel-functie verandert een webserver niet automatisch.

Dit artikel volgt daarom geen volledige chronologie van de releases. Het gaat in op functies die relevant zijn voor het gebruik van de huidige 6.x-kernels. Niet al deze functies zijn pas in de 6.x-reeks geïntroduceerd; doorslaggevend zijn de in de betreffende kernel beschikbare functionaliteit, mogelijke uitbreidingen en de gevolgen voor het geheugengedrag, CPU-concurrentie, procesisolatie en onderhoud.

Vier hostingpakketten

Voor hostingservers zijn vier bedrijfsgebieden bijzonder relevant: opslagdruk, CPU-concurrentie, extra procesisolatie en onderhoud. Het gaat hierbij niet om het activeren van zoveel mogelijk kernel-functies, maar om de juiste tools voor een geconstateerd probleem. PHP-FPM-pools, databases, caches, batch-taken en gespecialiseerde workers stellen verschillende eisen, die niet louter uit de kernelversie kunnen worden afgeleid.

cgroep v2 Dit is een overkoepelend thema, maar geen nieuwigheid in de 6.x-serie. De hiërarchie structureert geheugen- en CPU-bronnen voor diensten, containers of klantgroepen. Welke controllers beschikbaar zijn en in een subhiërarchie zijn geactiveerd, moet worden gecontroleerd bij de betreffende cgroup-v2-mount. Een speciale webserver moet daarom anders worden beoordeeld dan een container- of VM-host.

De tabel maakt bewust onderscheid tussen build-configuratie, opstartactivering, runtime-interface en daadwerkelijk gebruik. Een functie kan weliswaar in de kernel aanwezig zijn, maar gedeactiveerd zijn of voor de toepassing irrelevant zijn. Ook kunnen distributies functies terugporten. Beoordeel wijzigingen daarom op basis van belastingpatronen, cgroup-opbouw, hardware en applicatiestatistieken in plaats van op basis van het hoogste beschikbare versienummer.

Geheugendruk en Page Reclaim

Linux gebruikt vrij geheugen graag als bestandscache. Een groot deel van het RAM-geheugen dat in gebruik is, is daarom op zich geen fout en ook geen bewijs van geheugenverspilling: tijdelijk opgeslagen bestandsblokken kunnen indien nodig worden teruggewonnen. Voor de diagnose zijn vooral de ontwikkeling en de gevolgen van de belasting van belang, zoals responstijden, swap-activiteit, foutlogboeken en het afbreken van processen.

De opslagdruk is bepalend Pagina terugwinnen , welke pagina’s uit de cache kunnen worden verwijderd of, indien nodig, kunnen worden uitgelagerd. De kernel kan dit werk asynchroon uitvoeren via kswapd afhandelen. Als een proces bij een geheugenverzoek zelf pagina’s moet terugwinnen, spreekt de kernel-documentatie van ‘direct reclaim’; dit kan het verzoekende proces en daarmee de waargenomen latenties beïnvloeden.

Waarschuwingssignalen komen meestal in combinatie voor: aanhoudende swap-in of -out, OOM-gebeurtenissen, toenemende wachttijden en fouten op applicatieniveau verdienen een gezamenlijke tijdlijn. Een eenmalige piek kan daarentegen het gevolg zijn van een geplande batchtaak. Ook een cachedienst die veel RAM-geheugen in beslag neemt, is niet automatisch de oorzaak, mits de cgroup ervan en de overige processen voldoende functioneel blijven.

cgroup v2 vult het globale overzicht aan met grenzen op basis van diensten of containers. De opslagcontroller stelt gebeurtenistellers ter beschikking; memory.events is hiërarchisch, terwijl memory.events.local alleen lokale gebeurtenissen van de betreffende cgroup weergeeft. Zo kan worden vastgesteld of een probleem te wijten is aan de limiet van de eigen dienst of aan de belasting in een bovenliggende structuur.

Deze basisprincipes pleiten nog niet voor tuning. Voordat je limieten, de swap-strategie of kernel-interfaces aanpast, breng je de bronnen van de belasting, de cgroup-toewijzing en de temporele correlatie in kaart. Vooral een strenge geheugenlimiet kan ervoor zorgen dat een dienst vroegtijdig uitvalt, in plaats van de onderliggende piekbelasting op te vangen. Pas uit de diagnose blijkt of een wijziging überhaupt een geschikte technische aanpassingsmogelijkheid biedt.

Multi-Gen LRU gericht controleren

Multi-Gen LRU is een alternatieve implementatie voor Pagina terugwinnen en wordt beschreven in de hier besproken kernel-documentatie vanaf Linux 6.1. Bij geheugendruk moet de kernel beslissen welke bestandscache- of anonieme geheugenpagina’s kunnen worden vrijgemaakt. Multi-Gen LRU deelt pagina’s hiervoor in generaties in op basis van de tijd sinds de laatste toegang en houdt rekening met toegangs patronen, zodat het minder waarschijnlijk is dat vaak benodigde pagina’s worden geselecteerd voor vrijgave.

Dit is van belang voor een drukbezette webhostingserver waarop PHP-FPM-pools, een database en een cachedienst tegelijkertijd RAM-geheugen in beslag nemen. De functie kan de selectie bij het terugwinnen van geheugen beïnvloeden, maar is noch een geheugenuitbreiding, noch een garantie voor kortere responstijden. De werklast, de hoeveelheid RAM, de swapruimte, de opslagcapaciteit en de cgroup-limieten van de diensten blijven bepalend voor of en in hoeverre er een effect merkbaar is.

Controleer voor elke evaluatie eerst of de runtime-interface aanwezig en leesbaar is. In de actuele kernel-documentatie worden hiervoor de volgende configuratieopties genoemd: CONFIG_LRU_GEN en CONFIG_LRU_GEN_ENABLED en het pad onder /sys/kernel/mm/lru_gen/. Een distributiekernel kan functieniveaus terugporten of anders configureren; het versienummer alleen is daarom geen betrouwbaar bewijs.

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

Een uitvoer toont in eerste instantie alleen aan dat de gedocumenteerde sysfs-interface aanwezig en leesbaar is. Voor de activeringsstatus is de bitwaarde relevant: 0x0001 is de hoofdschakelaar van Multi-Gen LRU. Als dit bit ontbreekt, kan het bestand ondanks een beschikbare interface een gedeactiveerde hoofdschakelaar weergeven; andere bits hebben betrekking op aanvullende componenten. Ook een ingesteld hoofdbit is geen algemene aanbeveling om de waarde in de productie te wijzigen.

Schrijftoegang tot sysfs is daarom geen standaard-tuning. Leg eerst tijdreeksen vast voor Reclaim, Swap, latenties en cgroup-gebeurtenissen, documenteer bij een gerechtvaardigde wijziging de uitgangswaarde en bepaal een terugkeerpad. Zo blijft het traceerbaar of het waargenomen probleem daadwerkelijk is veranderd of dat er slechts meerdere instelparameters tegelijk zijn aangepast.

Je moet vooral voorzichtig zijn wanneer er sprake is van zowel krappe opslaglimieten als overboekte diensten. Een aangepast reclaim-algoritme lost geen te grote PHP-workerpools, ongeschikte databasecaches of een gebrek aan scheiding tussen concurrerende klanten op. De juiste volgorde is: de oorzaak en de betrokken cgroup vaststellen, de belasting beperken of verdelen en pas daarna een beschikbare kernel-functie als mogelijke beïnvloedende factor beoordelen.

Opslagproblemen nauwkeurig opsporen

Gebruikte RAM is op zich geen fout: Linux gebruikt het vrije geheugen specifiek als bestandscache. Er is eerder actie nodig wanneer de vereisten in directe terugwinning lopen, de swap-activiteit neemt toe, er treden OOM-gebeurtenissen op of verzoeken worden tegelijkertijd trager. Asynchrone reclaim door kswapd werkt op de achtergrond; directe terugwinning vindt daarentegen plaats in de context van de taak die geheugen vraagt en kan de uitvoering daarvan vertragen.

Het gebeurtenissenbestand memory.events telt gebeurtenissen hiërarchisch, dus inclusief onderliggende cgroups. Voor uitsluitend het lokale overzicht geldt memory.events.local klaar. high staat voor beperking en directe terugwinning na overschrijding van memory.high, terwijl oom een toewijzing die dreigt te mislukken vanwege de cgroup-limiet telt mee. oom_kill telt daarentegen processen van deze cgroup die door een of andere vorm van OOM-killer zijn beëindigd.

Begin de diagnose met een duidelijke toewijzing: welke dienst of container behoort tot de verdachte cgroup, wanneer deden de gebeurtenissen zich voor en welke applicatiesignalen waren er tegelijkertijd? Vergelijk vervolgens lokale en hiërarchische tellers, het systeemlogboek, de swapgeschiedenis, HTTP-latenties, wachttijden in de database of foutpercentages. Bij een OOM-geval moet bovendien worden nagegaan of de gegevens wijzen op een cgroup-gerelateerd proces of op een mogelijk globaal geheugen tekort.

De waarde memory.max is een strenge cgroup-limiet en geen eerste standaardmaatregel. Een strakkere limiet kan clients beschermen, maar kan een toepassing ook eerder in OOM-situaties brengen; een hogere limiet kan verdringing bij aangrenzende diensten versterken. Controleer daarom eerst het aantal workers, de cachegroottes, piekbelastingen en de cgroup-structuur. Wijzig vervolgens slechts één onderbouwde parameter, met een observatieperiode en een terugdraaiplan.

Inzicht in EEVDF en CPU-concurrentie

In de huidige officiële kernel-documentatie wordt het begin van de overgang naar EEVDF Linux 6.6. Het algoritme „Earliest Eligible Virtual Deadline First” verandert de selectie van normale, eerlijk ingeplande taken: er wordt rekening gehouden met virtuele looptijd, vertraging als afwijking van de ideale verdeling en virtuele deadlines. In aanmerking komende taken met de vroegste virtuele deadline kunnen daardoor als eerste CPU-tijd krijgen.

De term „overgang“ is belangrijk. EEVDF vervangt de selectiebeslissing van de Fair-Scheduling-klasse niet in die zin dat daarmee alle gegevensstructuren, interfaces en concepten die in het verleden als CFS werden aangeduid, verdwijnen. Ook in de huidige documentatie wordt EEVDF nog steeds vergeleken met CFS. Voor een specifieke distributiekernel moet daarom de geïntegreerde patch- en functiestatus worden gecontroleerd, in plaats van uitsluitend af te gaan op 6.6 of hoger, om te concluderen dat het gedrag volledig uniform is.

Voor hosting is deze wijziging vooral relevant bij een gemengde werklast. Webverzoeken, databasewerkzaamheden en monitoring concurreren bijvoorbeeld met importen, compressie of back-ups. Een ander latentieprofiel tussen kernelversies is mogelijk, maar leidt niet automatisch tot een hogere totale doorvoer. De scheduler lost geen problemen op zoals kernels die continu volledig bezet zijn, geblokkeerde processen, I/O-wachttijden en ongeschikte applicatieconfiguraties.

De operationele scheiding vindt nog steeds plaats op basis van dienst- en platformgrenzen. CPU-gewichten beïnvloeden de relatieve verdeling bij concurrentie, terwijl quota de beschikbare rekentijd kunnen beperken. Als latentiegevoelige webverkeer betrouwbaar moet worden gescheiden van omvangrijke batch-taken, kan ook een eigen VM of een aparte host aangewezen zijn. EEVDF vervangt deze Planning van hulpbronnen niet.

Alvorens de gegevens op te vragen van cgroup.controllers moet je nagaan of en waar cgroup v2 is gekoppeld. De volgende leesprocedure zoekt het cgroup-v2-koppelpunt in plaats van het gebruikelijke pad /sys/fs/cgroup ervan uitgaan. Op een puur cgroup-v1-systeem blijft de variabele leeg; bij een hybride hiërarchie geeft deze alleen de gevonden v2-mount weer.

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 verwijst alleen naar de huidige releasestring. cgroup.controllers geeft een overzicht van de controllers die in precies deze cgroup beschikbaar zijn voor activering; het bevestigt niet dat ze in de relevante subhiërarchieën zijn ingeschakeld. Daarvoor is onder andere cgroup.subtree_control op de betreffende hiërarchische niveaus te controleren. Controllers worden van boven naar beneden vrijgegeven, zodat een onderliggende cgroup alleen controllers kan doorgeven die door het bovenliggende knooppunt ter beschikking zijn gesteld.

systemd-cgtop geeft eveneens slechts een momentopname weer en is geen oorzakenanalyse. Verzamel gegevens over de CPU-belasting per dienstgroep, de latentie van verzoeken, de looptijden van batchtaken en, indien van toepassing, de I/O-wachttijden gedurende meerdere vergelijkbare piekperiodes. Als er alleen vertragingen optreden tijdens een back-up, zijn het tijdvenster, het CPU-gewicht of de quota daarvan meestal concretere eerste aanpassingen dan een veronderstelde afstemming van de scheduler.

Landlock voor gespecialiseerde werknemers

Landlock werd voor het eerst geïntroduceerd in Linux 5.13 en is daarom geen oorspronkelijke vernieuwing van de 6.x-serie. In 6.x-kernels zijn, afhankelijk van de release en de distributiekernel, verschillende, uitgebreide ABI-versies beschikbaar. De functie is een aanvullend beveiligingsmechanisme waarmee een proces zichzelf verder kan beperken.

Als stapelbare Linux Security Module werkt Landlock naast de reeds geldende toegangsbeslissingen; het vervangt noch Unix-bestandsrechten, noch SELinux, AppArmor, namespaces of containers. Regels kunnen onder andere de toegang tot het bestandssysteem beperken en worden doorgegeven aan vervolgens gestarte subprocessen. De daadwerkelijke functionaliteit is afhankelijk van de beschikbare ABI en de kernelconfiguratie.

Het is zinvol om Landlock vooral voor zelfontwikkelde of specifiek geselecteerde afzonderlijke processen. Een converter voor uploads van klanten zou alleen bestanden uit één invoermap mogen lezen en de resultaten uitsluitend naar één uitvoermap mogen schrijven. Zelfs als de dienst niet correct wordt verwerkt, mag deze noch SSH-sleutels, noch applicatiegeheimen, noch algemene systeempaden kunnen lezen. Deze beperking vormt een aanvulling op een zorgvuldige toewijzing van rechten; ze maakt deze niet overbodig.

Een productieve regel mag niet uitsluitend uitgaan van een actuele kernel. Landlock beschikt over verschillende ABI-versies; een toepassing moet tijdens de uitvoering nagaan welke ABI beschikbaar is en alleen toegangsrechten of functies aanvragen die door deze ABI worden ondersteund. Zo kan de toepassing op oudere systemen op een aangepaste manier werken, in plaats van volledig uit te vallen vanwege een niet-beschikbare interface.

Los daarvan ligt handled_access_fs legt expliciet vast welke toegangen tot het bestandssysteem door een regelset worden afgehandeld en standaard worden geweigerd als er geen passende regel is. Deze expliciete afspraak tussen de toepassing en de kernel voorkomt dat een sandbox alleen al door een systeemupdate ongemerkt strenger wordt en daardoor toepassingen niet meer werken. ABI-opvraging en expliciet behandelde rechten horen daarom bij elkaar, maar vervullen verschillende compatibiliteitstaken.

Voor de bestandsconverter volgt hieruit een stapsgewijze implementatie: de benodigde lees-, schrijf- en werkdirectory’s afleiden uit het daadwerkelijke verloop, rekening houden met foutpaden en deze eerst in de staging-omgeving testen. Een beknopt voorbeeldbeleid zou geen robuust productierecept zijn, omdat tijdelijke bestanden, externe bibliotheken en gestarte hulpprogramma’s mogelijk verdere toegang vereisen. Verdere maatregelen voor dienstisolatie komen ook aan bod in het artikel over Kernel-hardening voor hostingservers.

Bijzondere voorzichtigheid is geboden bij OverlayFS. Regels voor een overlay-laag beperken niet automatisch de samengevoegde mount-hiërarchie en omgekeerd. Container- en build-omgevingen met overlays vereisen daarom een afzonderlijke controle van de specifieke mounts en toegangspaden. Landlock is daar een mogelijke extra laag, maar geen algemene scheiding van tenants en geen vervanging voor een degelijk container- of autorisatieconcept.

DAMON alleen voor bijzondere gevallen

DAMON en de daarop gebaseerde Reclaim-mechanismen kunnen niet zonder meer worden aangemerkt als functies die voor het eerst in Linux 6.x zijn geïntroduceerd. Voor beheerders is de functionaliteit van de daadwerkelijk gebruikte 6.x- of distributiekernel van belang. DAMON houdt geheugentoegangen bij met als doel gebieden te kunnen indelen op basis van hun gebruiksgedrag.

Op basis daarvan probeert DAMON_RECLAIM, om geheugen dat al lange tijd niet is gebruikt proactief terug te winnen door middel van lichte druk. Deze methode vormt een aanvulling op de normale, op LRU gebaseerde terugwinning; het is niet de bedoeling dat deze de normale methode vervangt. In de kernel-documentatie wordt dit toegeschreven aan algemene overboekte geheugensystemen en wordt virtualisatie op basis van Free-Pages-Reporting als voorbeeld genoemd.

In dit virtualisatiescenario is het niveau doorslaggevend: gasten melden aan de host welke geheugenpagina’s vrij zijn, zodat de host deze aan andere gasten kan toewijzen. Als een gast slechts weinig vrij geheugen meldt, terwijl hij pagina’s vasthoudt die al lange tijd niet zijn gebruikt, kan proactieve terugwinning als gast bijdragen aan het melden van meer vrije pagina’s aan de host. DAMON_RECLAIM is dus niet zonder verdere controle een oplossing aan de hostzijde voor ongebruikt werkgeheugen van gasten.

Voor een afzonderlijke web- of databaseserver is dit daarom geen standaardmaatregel. Ook in gevirtualiseerde omgevingen moet eerst duidelijk zijn op welk niveau de druk ontstaat en of langdurig ongebruikte gebieden daadwerkelijk de oorzaak zijn. CPU-bottlenecks, trage opslag, ongeschikte cgroup-limieten of actieve applicatiecaches kunnen dezelfde symptomen verklaren, zonder dat proactieve reclaim de juiste oplossing zou zijn.

Quota’s, leeftijdsgrenzen en watermerken bepalen wanneer en in welke mate DAMON_RECLAIM actief is. Het zijn geen standaardwaarden die zomaar kunnen worden overgenomen: een te agressieve selectie kan nuttige bestandscache of herhaaldelijk benodigde geheugenpagina’s voortijdig verdringen. Dit kan extra I/O-bewerkingen veroorzaken en CPU-tijd in beslag nemen voor herhalingswerk, hoewel de nominaal vrije geheugencapaciteit toeneemt.

Een weloverwogen beslissing vereist daarom metingen met duidelijke vergelijkingsgrootheden, zoals vrije opslagruimte zoals gerapporteerd door de gebruiker, reclaim-activiteit, swap-gedrag, opslaglatentie en responstijden van applicaties. Test wijzigingen eerst in een vergelijkbare staging-omgeving, zorg voor een terugvalplan en observeer ze tijdens representatieve belastingfasen. Als aan deze voorwaarden niet wordt voldaan of als de oorzaak van de opslagdruk onduidelijk is, blijft DAMON bewust uitgeschakeld.

Updates, live-patching en herstarts

Het onderhoud van de kernel begint met het vergelijken van het beveiligingsbericht, het geïnstalleerde pakket en de kernel die daadwerkelijk draait. Controleer vervolgens in de instructies van je eigen distributie welke correctie voor precies deze kernelvertakking is bedoeld en of een herstart vereist is. Een hoger 6.x-versienummer op zich wijst noch op de aanwezige patch, noch op de beschikbaarheid van een geschikte livepatch; beveiligingscorrecties kunnen ook worden teruggeporteerd naar oudere distributiekernels.

Ook Live-patching werd niet pas met Linux 6.x als concept geïntroduceerd. De infrastructuur die relevant is voor 6.x-kernels maakt het mogelijk om bepaalde kernelwijzigingen tijdens de looptijd door te voeren. Cumulatieve livepatches kunnen daarbij een oudere patch atomair vervangen door een nieuwere. De gedocumenteerde beperkingen hebben onder andere betrekking op statuswijzigingen, callbacks en het terugschakelen tussen patches.

Of er voor een specifieke distributiekernel een geschikte livepatch beschikbaar is, moet worden gecontroleerd aan de hand van het betreffende aanbod en de goedkeuringen van de aanbieder. Uit de algemene kernel-infrastructuur volgt noch dat elke beveiligingscorrectie live beschikbaar is, noch dat een geïnstalleerde patch een volledige kernel-update permanent vervangt. Plan daarom ook in de toekomst nog steeds regelmatige onderhoudsvensters in.

Beoordeel eerst de urgentie en de impact van een update, vergelijk vervolgens de pakketstatus en de actieve kernel en controleer het concrete Livepatch-aanbod. Na een reguliere kernel-update met een herstart controleer je of de verwachte kernel actief is en of de kritieke diensten, netwerkpaden, back-ups en de monitoring correct werken. Deze controle maakt deel uit van het onderhoudsproces en mag niet worden afgeleid uit de loutere bereikbaarheid van de server.

A geplande doorstart kan ondanks livepatching toch nodig blijven. Wijzigingen in de opstartparameters van de kernel worden doorgaans pas bij de volgende opstart doorgevoerd. Bij stuurprogramma's, apparaatfirmware en hardware hangt de werkwijze daarentegen af van het onderdeel, de manier waarop het is geïntegreerd en het fabricageproces: in sommige gevallen volstaat het om een module, apparaat of dienst opnieuw op te starten, in andere gevallen is een volledige herstart van de host nodig.

Het aanvullende artikel over Livepatching op AlmaLinux-servers gaat in op een concrete, distributieafhankelijke implementatie. Pas dergelijke procedures niet zonder controle toe op andere kernelvertakkingen of leveranciers. Bepalend zijn de pakketten, de ondersteunde kernelversies en de gebruiksinstructies van het daadwerkelijk gebruikte platform.

• Verander bewust niets als de geconstateerde storing nog geen aanwijsbare oorzaak heeft.
• Plan geen livepatch of kernelaanpassing zonder een passende staging-test en een gedocumenteerde terugkeerprocedure.
• Activeer geen functie als de betreffende toepassing of het betreffende platform de bijbehorende interface niet gebruikt.
• Ga er niet vanuit dat een ontbrekend onderhoudsvenster kan worden gecompenseerd door te veronderstellen dat livepatching elke kernelupdate dekt.