Linux-kernel 4.0 hoeft niet meer te rebooten voor updates - update

Een samenwerking op de Linux Plumbers Conference 2014 tussen ontwikkelaars van Red Hat en SUSE heeft geleid tot een opensourcepakket om updates voor de Linux-kernel te installeren zonder dat het systeem herstart hoeft te worden.

In het verleden zijn al vaker tools uitgebracht om te kunnen patchen zonder te moeten herstarten. Tweakers berichtte in 2008 bijvoorbeeld over Ksplice, maar dat werd in 2011 door Oracle overgenomen om de dienst vervolgens alleen beschikbaar te maken voor Premier Support-klanten. CloudLinux sprong in 2014 in dat gat met KernelCare, alleen maakt dat programma deels gebruik van propriëtaire software en moeten gebruikers een maandelijkse vergoeding betalen.

Dat laatste zinde zowel Red Hat als SUSE niet en beide bedrijven begonnen met het ontwikkelen van opensourcecode om Linux te kunnen patchen zonder herstarten van het systeem. Red Hat ontwikkelde kpatch en SUSE kGraft. Beide programma's maken gebruik van ftrace om te kijken of de patch veilig kan worden doorgevoerd. Ondanks dat het eindresultaat hetzelfde is, zijn er wel duidelijke prestatieverschillen. Bij kpatch duurt het van één tot veertig milliseconden, terwijl het bij kGraft tot enkele minuten kan duren voor een patch is doorgevoerd. Bij beiden is nooit last van downtime.

ZDnet schrijft dat de twee groepen op de Linux Plumbers Conference in oktober 2014 de handen ineensloegen om uiteindelijk code uit beide programma's in de Linux-kernel 4.0 te verwerken. Volgens een van de ontwikkelaars van SUSE, Jiri Kosina, gaat het om een relatief simpele en minimalistische methode omdat zo veel mogelijk gebruikgemaakt wordt van de bestaande kernel-infrastructuur, aangevuld met een api voor kernelmodules waar de eigenlijke patches inzitten, en een api voor de gebruikersomgeving om te kunnen werken aan de patches. "Het is ook opzichzelfstaand in de zin van dat het niet aan andere kernel-subsystemen aanhaakt", verklaart de ontwikkelaar.

Met het uitkomen van de release candidate van de Linux-kernel 4.0 is het nu alleen voor x86 geïmplementeerd als referentiearchitectuur, maar ondersteuning voor powerpc, s390 en ARM komt eraan. Dat de code nu in de kernel zit, wil niet zeggen dat het direct bij alle Linux-distributies werkt, aangezien de patches er ook gebruik van moeten gaan maken.

Update, donderdag, 13.45: Tweaker HiGHGuY merkt terecht op dat de patches van kGraft of kpatch zelf niet in de kernel zitten. Er moet nog heel wat werk verzet worden voordat het mogelijk is een live-patch door te voeren. De toegevoegde code in de 4.0-kernel is gedeelde code tussen kGraft en kpatch. Er is nu een api die modules met een patch kan toestaan in de kernel gevoegd te worden. Het consistency model mist in dit verhaal. Dat model is nodig om veilig te kunnen wisselen tussen versies van een functie in een draaiende kernel. De behandeling van dat model verschilt tussen kGraft en kpatch, waardoor die eerst samengebracht moet worden.

Het uitgebreide artikel op lwn.net haalt verschillende obstakels aan. Het besluit met het vermoeden dat het werk aan een live-patching-mogelijkheid voortgezet wordt, maar dat het nog niet duidelijk is welke kant het op zal gaan. De hoop wordt uitgesproken dat de code van het consistency model klaar is voor de 4.1-kernel-merge. Anderzijds is er nog steeds twijfel óf een dergelijke mogelijkheid wel ingebouwd moet worden.

Reacties (85)

[mugenmarco]

Ik denk dat ik er overheen lees, maar waarom moet een systeem bij bepaalde updates opnieuw opstarten? Ik weet dat als een update geinstalleerd word die een process of service vervangd dat de computer herstart moet worden omdat het bestand meestal in gebruik is en dan niet overschreven kan worden.

Maar denk dat ik er naast zit, wie heeft de uitleg?

[Inspector]

Het gaat hier ook niet zozeer om een service of applicatie. Op linux is het al sinds jaren mogelijk dit te updaten zonder reboot. Zelfs drivers kunnen relatief eenvoudig geüpdatet worden zonder te herstarten. Het gaat hier voornamelijk om kernel modules of zelfs een complete nieuwe kernel. Essentiële onderdelen binnen de kernel die b.v. I/O regelen. Hiervoor was soms een reboot nog wel nodig en bij een nieuwe kernel altijd. Dat is nu schijnbaar opgelost.

[Reactie gewijzigd door Inspector op 23 juli 2024 21:46]

[H!GHGuY]

Helaas is dit onjuist.

Er is infrastructuur in de kernel gestopt die gemeenschappelijk is tussen kGraft en kpatch.
De kernel bevat echter nog niet kGraft of kpatch zelf. Er is dus met 4.0 geen sprake van live kernel-patching. T.net slaat wederom de bal mis bij het rapporteren over kernel updates.

De auteurs van beide patchsets zijn nu aan het samenwerken om het beste van beide werelden te nemen en dat in de kernel te stoppen. Het is echter nog maar de vraag of die functionaliteit er ooit zal komen, aangezien er weerstand is tegenover beide implementaties en het nog niet duidelijk is of er echt vraag is naar deze features.

Ik vermoed dat T.net beter ook een abbonement neemt op LWN.net, dan had ze dit artikel kunnen lezen die alles haarfijn uitlegt:
https://lwn.net/Articles/634649/

[Anoniem: 112442]

Helaas is dit onjuist.

Er is infrastructuur in de kernel gestopt die gemeenschappelijk is tussen kGraft en kpatch.
De kernel bevat echter nog niet kGraft of kpatch zelf. Er is dus met 4.0 geen sprake van live kernel-patching. T.net slaat wederom de bal mis bij het rapporteren over kernel updates.

De auteurs van beide patchsets zijn nu aan het samenwerken om het beste van beide werelden te nemen en dat in de kernel te stoppen. Het is echter nog maar de vraag of die functionaliteit er ooit zal komen, aangezien er weerstand is tegenover beide implementaties en het nog niet duidelijk is of er echt vraag is naar deze features.

Ik vermoed dat T.net beter ook een abbonement neemt op LWN.net, dan had ze dit artikel kunnen lezen die alles haarfijn uitlegt:
https://lwn.net/Articles/634649/

Klopt je opmerking wel?

Zie dezekGraft slide show pagina ...

• Publishing
‒ kGraft code has become available in a GIT repository TODAY
https://git.kernel.org/cg.../git/jirislaby/kgraft.git

Zie ook, deze SUSE kGraft informatie pagina.

Tevens gebruikt SUSE KGraft al in de SLES12.

kGraft was made available for SUSE Linux Enterprise Server 12 on November 18, 2014, as an additional feature called SUSE Linux Enterprise Live Patching.

Zie ook: No reboot patching comes to Linux 4.0

Jiri Kosina, a SUSE software engineer and Linux kernel developer, explained, that live-patching in the Linux kernel will "provides a basic infrastructure for function "live patching" (i.e. code redirection), including API [application programming interface] for kernel modules containing the actual patches, and API/ABI [application binary interface] for userspace to be able to operate on the patches. This is "relatively simple and minimalistic, as it's making use of existing kernel infrastructure (namely ftrace) as much as possible. It's also self-contained, in a sense that it doesn't hook itself in any other kernel subsystem (it doesn't even touch any other code)."

The release candidate for Linux 4.0 is now out. Kosina stated that "It's now implemented for x86 only as a reference architecture, but support for powerpc, s390 and arm is already in the works." And, indeed, the source code for these architectures is already in the Live Patching Git code.

Simply having the code in there is just the start. Your Linux distribution will have to support it with patches that can make use of it. With both Red Hat and SUSE behind it, live patching will soon be the default in all serious business Linux distributions.

[Reactie gewijzigd door Anoniem: 112442 op 23 juli 2024 21:46]

[H!GHGuY]

Ja, wat jij aangeeft is SuSe specifiek en gaat niet over de mainline kernel.
SuSe (en zowat all distributies) wijzigen de mainline kernel vooraleer ze te shippen naar hun klanten. SuSe zal dus ongetwijfeld bovenop het stukje wat in de kernel terecht is gekomen, hun kGraft hebben gezet voor hun klanten.

De mainline kernel (die Linus onderhoudt) bevat echter dat stukje niet.

[Anoniem: 112442]

Ja, wat jij aangeeft is SuSe specifiek en gaat niet over de mainline kernel.
SuSe (en zowat all distributies) wijzigen de mainline kernel vooraleer ze te shippen naar hun klanten. SuSe zal dus ongetwijfeld bovenop het stukje wat in de kernel terecht is gekomen, hun kGraft hebben gezet voor hun klanten.

De mainline kernel (die Linus onderhoudt) bevat echter dat stukje niet.

Lees het laatste stukje, van zdnet (opmerking van Jiri Kosina), a.u.b. de RC 4.0 kernel heeft het wel. En deze (de 4.0 Kernel) zal hiermee geleased worden.

Of de Redhat code er wel in zit/zal zitten weet ik niet. Maar jij gaf aan dat het er beide niet in zit.

[H!GHGuY]

Ik vertrouw een lwn.net artikel 1000 maal meer dan een ZDnet artikel.

[Anoniem: 112442]

Ik vertrouw een lwn.net artikel 1000 maal meer dan een ZDnet artikel.

De opmerking was van Jiri Kosina van SUSE Labs. Niet van ZDnet. Ze hebben het alleen opgeschreven.

[pegagus]

Waarom zou er geen vraag zijn? Juist omdat Linux veelal op servers draait, wil je zo min mogelijk opnieuw opstarten.

Verder snap ik je opmerking over de weerstand tegen de implentatie ook niet helemaal. De kernel is modulair, dus wat je er niet in wilt, compilleer je niet mee.

En off-topic: het spreekwoord is de plank mis slaan.

[H!GHGuY]

Lees de link die ik aanhaal. Die is vandaag voor iedereen toegankelijk en daar wordt alles haarfijn uitgelegd.

[leuk_he]

In principe hoeft rebooten niet. Maar de puzzel om op 20439 configuraties te bepalen welke bestanden wel en niet gelocked kunnen worden, en welke executables welke versie van een dynamische library gebruiken is niet simpel. Op linux wordt er wat meer tijd aan besteed om dat te regelen, onder windows is een beetje een mentaliteit onstaan, reboot maar, dan start alles in de nieuwe staat op.

Ook windows heeft wat mechanismen om de dll-hell te ontwarren, maar dan moeten ontwikkelaars daar zich wel druk over maken. En aangezien de installer er maar even achteraan gezet wordt krijgt dat punt meestal niet zoveel aandacht als alle honderd features die er ook toe doen.

Vroeger wou je windows ook rebooten als je de PC in een ander netwerk hing, nu weet je met wifi niet anders dan dat dat dynamisch kan. Linux heeft al veel langer het principe dat je alleen een subsysteem hoeft te herstarten. windows hangt veel meer in elkaar, en het herstarten van 1 subsysteem verknoeit andere subsystemen. Dus reboot men maar.

Overigens krijgt linux met systemd ook steed meer last van dat alles met alles integreert, waardoor reboot (wat dan wel meer sneller gaat met systemd), eerder een optie is.

[UPPERKEES]

Beetje BS over systemd... Systemd maakt het systeem juist solider dan losse slecht geschreven bash scripts die totaal niet bewust zijn van de rest van het systeem. Of nauwkeurig de running state kunnen bepalen. Dus leg dat eens uit.

[mkools24]

Bij systemd raak je sneller het overzicht kwijt, dus denk je ik reboot maar want dan zal mijn aanpassing wel (her)(ge)laden worden. Persoonlijk vind ik systemd ook te onduidelijk, niet overzichtelijk en zelfs chaotisch en daarom gebruik ik het ook bewust niet. Ik denk dat 'leuk_he' dat ook bedoelt.

Enneh zolang systemen nog backwards compatible zijn, waardoor je systemd kunt mixen met init scripts zal ook systemd nooit nauwkeurig de running state van je systeem kunnen bepalen dus ik blijf lekker op initd zitten zolang het kan en ondersteund wordt.

[_JGC_]

Op debian zijn init scripts hybride, als systemd actief is wordt systemctl aangeroepen ipv die buggy shellscript meuk.

Ik heb te vaak init scripts gezien die niet werken omdat er ergens een pidfile nog rondslingert. Geef mij dan maar gewoon systemd.

[UPPERKEES]

Ik denk dat jij even een cheatsheet moet checken van systemd. Het is absoluut niet onduidelijker, check de vele commando's maar eens ;-)

[mkools24]

Vroeger wou je windows ook rebooten als je de PC in een ander netwerk hing, nu weet je met wifi niet anders dan dat dat dynamisch kan.

Dit doet me denken aan Windows 95 destijds. Als je het IP adres veranderde moest je de Windows CD erin stoppen en ging Windows bestanden kopieren (die er al stonden) en vervolgens moest je ook nog rebooten.

Ben blij dat die tijd voorbij is maar ik ben nog steeds van mening dat Windows nog steeds teveel reboots nodig heeft ivm Linux. Wat Windows ook nog steeds heeft is als je een probleem hebt reboot dan eerst maar want in 90% van de gevallen werkt het daarna weer en is je probleem weg. In Linux heeft een reboot voor mij zelden tot nooit een probleem verholpen.

[wackmaniac]

Nou, bij mij wil een reboot nog wel eens issues met (Ubuntu) Linux verhelpen. Juist als je een paar updates hebt geïnstalleerd wil de boelwat instabiel worden. Overigens heb ik het idee dat ik mijn Linuxmachine minstens net zo vaak moet rebooten als dat ik dat met Windows moest. Bijna elke week, soms wel twee keer per week vereisen updates een reboot.

[Fermion]

Nog steeds zo met het toevoegen van printers, eigenlijk wanneer je op een bestaande printer iets moet aanpassen. Binnen Windows is het afhandelen van printers nog steeds niet helemaal lekker geregeld.

[daft_dutch]

In principe hoeft rebooten niet.

Als er een nieuwe kernel versie is ben je echt wel verplicht eerst je draaiende kernel te stoppen en dan de nieuwe versie laden. (reboot/kexec) en voor als er oneffingheden in je draaiende kernel zitten. Waar dit voor bedoelt is.
De grote beperkende factor is dat de data structuur voor en na de "patch" excact het zelfde moet zijn. Wat waarschijnlijk al het gecheck is wat kGraft doet.

daarbij.

Maar de puzzel om op 20439 configuraties te bepalen welke bestanden wel en niet gelocked kunnen worden

Dat zijn reguliere updates voor linux appeltje eitje sinds 1998

[lordfragger]

Als in linux een nieuwe kernel versie geïnstalleerd wordt dan wordt die nieuwe naast de oude gezet. Na een reboot wordt de nieuwe dan gebruikt.

Wat ze hier doen is de kernel die in memory zit aanpassen, waardoor je dus die reboot niet meer nodig hebt.

[himlims_]

ksplice

[johnkeates]

Het verschil tussen een applicatie en een kernel is dat je een applicatie kan herstarten maar een kernel niet. Nouja, je kan een kernel dus wel herstarten, maar dat heet dan 'de computer herstarten'

Wat ze nu doen is het hele herstarten overslaan en in-place upgraden. Dit kan in theorie ook gewoon met applicaties zodat die ook met nul downtime bijgewerkt kunnen worden.

[r_j]

Vergelijkbare functionaliteit bestond al in 1982 in UNIX-RTR (DMERT). De 3B20D systemen waar dit op draaide werden veel gebruikt in de tecom industrie waar een downtijd van max 3 min/jaar toegestaan werd. In de basis werd een nieuwe functie in geheugen geplaatst en een wijziging in de transfer table (waar het fysieke adres van elke functie staat) gemaakt om niet naar de oorspronkelijke functie te wijzen, maar naar een beslissingsfunctie. Deze functie verwees dan naar de oude functie als de call van een return (van een call van een andere functie) kwam. Als het daarentegen een nieuwe tread was dan werd naar de nieuwe functie verwezen. Na enige tijd kon dan de fix worden gecommit waarbij de beslissingsfuncties en de oude funties verijderd worden. Er zijn dan maar heel weinig dingen die je niet kunt patchen.

[computerjunky]

Tja voordelen maar ook nadelen zo kan er onzichtbaar crap naar je pc gepushed worden zonder dat je het door heb en de werking van je pc veranderen.

Ik werk nog altijd met het 'if it aint broken dont try to fix it' idee.

Ik wil geen updates totdat ik beslis of ik ze nodig heb of niet en het risico wil nemen dat ik wat anders om zeep help met de update.

[m8ZBm1Si]

Dit heeft daar niks mee te maken. Dit zijn geen silent updates. Dit zijn updates die geen reboot nodig hebben.

Verder, Linux draait voornamelijk op servers, en downtime is kostbaar. Technisch gezien is het dus wel broken, en het wordt nu gefixed.

[goarilla]

Verder, Linux draait voornamelijk op servers, en downtime is kostbaar. Technisch gezien is het dus wel broken, en het wordt nu gefixed.

Servers bevatten ook nog Raid/HBA kaarten met hun eigen BIOS en test-routines. Het booten daarvan neemt vaak enkele minuten in beslag.

[_JGC_]

Rebooten kan ook gewoon snel met kexec, daarbij wordt het hele boot proces tot en met de bootloader omzeild.

[mxcreep]

Yep, reboot maar eens een Dell server... zit minuten lang te wachten tot alles geinitialiseerd en gechecked is voor de daadwerkelijke OS boot begint.

[CAPSLOCK2000]

Vergeet ook niet allerlei consumentenapparatuur als telefoons, televisies en routers. Het zou wel tof zijn om je telefoon te upgraden zonder dat je hoeft te stoppen met bellen of je router te patchen zonder dat je paar minuten geen internet hebt.

[lordfragger]

Dit is dan ook helemaal niet ontwikkeld voor je pc thuis, maar voor servers in 24/7 omgevingen waar downtime ongewenst is.

Op deze manier komen we wel heel dicht bij zero downtime systemen die geen fortuin moeten kosten.

[CAPSLOCK2000]

Ik denk juist dat het bedoelt is voor kleine servers en consumentenspul. De echt belangrijke servers worden wel zo ingericht dat je twee of meer systemen hebt die elkaars taken kunnen overnemen. Alles gaat een keer stuk en alles heeft vroeg of laat onderhoud nodig. Als je systeem echt heel belangrijk is dan zorg je wel dat je het kan onderhouden zonder de dienstverlening te onderbreken.
Er zijn echter een hoop consumenten en kleine bedrijven die hun systemen nooit herstarten en daarom flink achterlopen met patches.

[lordfragger]

Bij servers die active-active draaien heb je in de meeste gevallen nog altijd een impact op lopende transacties op het moment dat een server down gaat. Daar zijn uiteraard oplossingen voor, maar die zijn kostelijk en/of zeer complex.

Als patches geen downtime meer veroorzaken is dat zeker mooi meegenomen voor zo'n systemen ook.

[cyberstalker]

Die complexiteit valt vaak wel mee. Een goede loadbalancer (zoals bijvoorbeeld haproxy) heeft meestal gewoon de optie een server in 'maintenance mode' te zetten. Daar maken wij op het werk bijvoorbeeld gebruik van:

• Zet server in maintenance mode
• Wacht tot alle open connecties zijn afgehandeld
• Herstart de server
• Wacht totdat de server weer up is
• Zet maintenance mode uit

Bij het gebruik van de maintenance mode worden er dus geen nieuwe requests meer naar de server gestuurd, maar worden de bestaande acties nog wel afgehandeld. Wij hebben zelf een ansible-script dat op deze manier een rolling update van alle servers kan doen, zonder downtime.

[mxcreep]

HAProxy is maar een deel van de oplossing hierin en idd dat deel werkt goed en is niet al te complex. Je zult echter bij het gebruik van meerdere servers voor een service wel gedeelde storage, replicatie of dat soort zaken nodig hebben en dat is lang niet altijd simpel en zeker ook niet altijd goedkoop. Wij clusteren en loadbalancen ook heel veel maar het is zeker wel complexer en ook de upgrade procedures zijn toch wel iets gevoeliger. Dus minder downtime door niet hoeven rebooten zal zeker in heel veel gevallen een welkome aanvulling zijn.

[MAX3400]

Een Linux kernel update is vaak al lang van te voren aangekondigd, volledig optioneel en je kan tot op de laatste wijziging nauwkeurig inlezen wat er gaat veranderen.

Er wordt dus niets ongevraagd gepusht noch geinstalleerd en al helemaal geen crap; je werkt enigszins arbitrair/achterhaald met je PC. Ook updates voor Windows en OSX zijn vaak goed gedocumenteerd en scheduled te downloaden & installeren.

[robvanwijk]

Er verandert niets aan de manier waarop je kiest welke updates je installeert, alleen aan de methode waarop ze geïnstalleerd worden. Als iemand straks "crap naar je kan pushen", dan kan die dat nu ook al; het enige verschil is dat de crap die je nu silent gepushed krijgt (al heb ik werkelijk geen idee hoe je dat voor elkaar krijgt) pas actief wordt na een reboot.

Een computer (zeker een server) compleet moeten rebooten om een klein subsystem bij te werken naar de nieuwste versie is "broken". Niet dusdanig hard "broken" dat je systeem compleet onbruikbaar wordt, maar je zit wel met een gigantisch workaround die je na elke update moet doorlopen (namelijk, een reboot).

Lees het artikel alsjeblieft opnieuw, want dat is totaal niet wat er hier aan de hand is.

[Anoniem: 445817]

Je hoeft je kernel natuurlijk niet te updaten als je dat niet wilt, ook met deze nieuwe API niet. Ik ga er ook vanuit dat je gewoon 4.0 kernels kunt compileren waar deze API niet in zit, net zoals je de meeste andere kernel features compile-time al uit kunt zetten.

Over "if it ain't broken don't try to fix it" kunnen we kort zijn: software is always broken. De enige vraag is wanneer de volgende bug ontdekt wordt en of het niet-patchen van deze nieuwe bug voor jou onacceptabele risico's met zich meebrengt.

[Ford Prefect]

Het probleem met je 'if it aint broken dont try to fix it' idee is dat als het echt kapot gaat de kans op business impact groot is. Ik ben bij heel veel trainwrecks geweest die allemaal niet waren ontstaan als er gewoon netjes maintenance/patch windows waren geweest. Patches zijn je vriend als je gaat voor een betrouwbare infrastructuur. Als dit net zo fijn gaat werken als ksplice (wat helaas door Oracle nu enorm niet wordt gebruikt, zelfs op hun Engineerd Systems zoals Exadata is het gebruik zeldzaam) dan ben ik blij met deze ontwikkeling.

[Soldaatje]

Handig dat niet hoeven rebooten, scheelt een hoop.
Ook mooi dat twee concurrenten gaan samenwerken om hetzelfde doel te bereiken.

[Robtimus]

Zoals ik het lees hebben ze niet samengewerkt maar werken ze in parallel aan verschillende oplossingen voor hetzelfde probleem.

[Anoniem: 191561]

Aansluitend hebben ze de beide oplossingen bekeken en samengevoegd, het resultaat is opgenomen in 4.0

[Niemand_Anders]

Niet helemaal. Dergelijke tools bestaan uit een deel kernel space en een deel userspace. Het user space gedeelte is nog steeds volledig gescheiden.

Men men nu heeft gedaan is dat men heeft gekeken wat beide kernel space onderdelen doen en op welke manier. Vervolgens hebben ze op basis van beide implementaties een soort van common 'update' API voor het kernel space gedeelte geschreven. Die common API zit nu in de kernel.

Persoonlijk vind ik het wel jammer dat men ook niet de rest van kPatch en kGraft hebben samengevoegd. Wat juist hier schuilt toch wel het grootste obstakel voor Linux om echt door te breken op de desktop. De tooling is te veel gefragmenteerd. Meer keuze is niet altijd goed.

Ik heb het project al enige tijd niet meer gevolgd, maar ik hoop dat distributies niet hoeven te kiezen uit kPatch of kGraft, want dan zal het resultaat waarschijnlijk zijn dat het minimaal ingezet zal worden, tenzij het redelijk eenvoudig is om de update geschikt te maken voor beide update frameworks.

RedHat zal natuurlijk niet snel met kGraft komen, maar ik ben benieuwd of ik straks bij Debian 8 kan kiezen welke kernel updater ik wil gebruiken of dat men de keuze voor mij maakt.

[matjojo]

er staat aan het einde at ze later hebben samengewerkt om een programma te make en die in de kernel te doen.

[Breezers]

Beide programma's maken gebruik van ftrace om te kijken of de patch veilig kan worden doorgevoerd

Zover ik het dan lees, geldt dit dus voor patches die geen herstart nodig hebben, maar betekend dit niet automatische dat er nooit meer herstart hoeft te worden bij installeren van patches ? maw als de patch uitgevoerd kan worden zonder herstart, dan gebeurt er niets, maar als de patch een herstart nodig heeft, dan gaat er een herstart plaatsvinden ? of zie ik dit verkeerd ?

[Joolee]

Ik denk dat er vooral gebruik gemaakt wordt van ftrace om te spotten of bepaalde delen van de kernel momenteel actief in gebruik zijn. In dat geval moet er gewacht worden met het switchen naar de nieuwe module,

[CAPSLOCK2000]

Er zijn nog steeds veranderingen die zo ingrijpend zijn dat je zal moeten herstarten. Ik verwacht wel dat het steeds minder zal worden omdat de kernel-programmeurs er vanaf nu rekening mee gaan houden.

[superlion]

Mooi dat het er is maar volgens mij wel vele jaren te laat
Vroeger waren de pc's zo traag dat je tussendoor naar de snackbar kon gaan voordat ie opnieuw was opgestart en toen hadden we dit moeten hebben
Nu kan je nog net 1x gapen en je systeem en programma's is bijna alweer compleet geladen

[Anoniem: 445817]

Voor PC's heb je gelijk, die zijn tegenwoordig vrij vlot. Zeker met een SSD ipv een traditionele harde schijf.

Servers zijn echter een ander verhaal. Een server van een beetje formaat is als snel minuten lang bezig met het testen van het RAM geheugen, het booten van de RAID array, eventuele file system checks, etc.

[Orthodroom]

Bij ons draaien alle Linux servers virtueel. Daarbij maakt het dus niet veel uit qua opstarttijd ondanks dat het zakelijk is en op een server draait.

[Lennie]

Wat jij moet doen is kijken naar kexec en CRIU in de gaten houden:
http://criu.org/Usage_scenarios#Seamless_kernel_upgrade

:-)

[Megamind]

Ik denk dat ze met Linux gebruikers 90% wel servers bedoelen en niet de thuisgebruiker. Wij hebben linux servers met raid controllers die er best lang over doen om weer helemaal op te komen, ben je toch zo 5 minuten down, niet handig voor een live product omgeving.

[Mopperman]

Daarvoor hebben ze maintenance windows

[GekkePrutser]

Dat is waar, maar ook die zijn niet gunstig als je een 24/7 userbase bedient.

En die zijn ook voor de medewerker niet prettig, want meestal liggen ze tussen de 2 en 4 uur 's nachts

[Mopperman]

Zijn ook oplossingen: Redundantie

Server 1 plat, server 2 neemt t over
update server 1, daarna alles over naar 1 en update je nummer 2.

Als je grote partij bent/grote userbase hebt mag je dit soort redundantie haast wel verwachten...

[divvid]

dat werkt alleen als je kort lopende userprocessen hebt, op onze server lopen regelmatig processen die dagen en soms wel weken nodig hebben. Dan reboot je niet zomaar.

[mjz2c00l]

2 servers (of meer), nieuwe processen op de 2e server, lopende processen afhandelen en geen nieuwe processen meer op de 1e server en daarna reboot, en dan de processen weer op de 1e server

[Megamind]

Plus maintenance windows zijn weer lastig voor hotfixes.

Daarnaast, omgevingen virtualizatie hebben vaak moeite om een reboot uit te voeren, bij RackSpace is het elke maand wel raak en gaat mijn server offline, terwijl dat soms helemaal niet uitkomt.

[ASS-Ware]

Daarvoor hebben ze maintenance windows

Maintenance windows worden vaak i.o.m. de gebruiker / applicatiebeheerder vastgesteld, maar ook de gebruiker / applicatiebeheerder wil soms tijdens die windows changes doorvoeren, en dan kun je alsnog als serverbeheerder de reboot niet uitvoeren.

[Yggdrasil]

Ik moet voor kernel-upgrades op onze productieservers 's nachts overwerken wat voor mij niet fijn is en mijn baas extra geld kost. Ik ben dus blij met deze ontwikkeling.

[Anoniem: 49516]

Daarom draaien we hier een combinatie van kernelcare en ksplice. Doe je het in de avond, want is de server hard aan het werk, duurt het patchen langer. Is de paar dollar in de maand meer dan waard...

[goarilla]

Volgen die dan de kernels van Red Hat, SUSE en bouwen ze enkel daar ksplice patches voor of is er ook support voor de meer obscure distro kernels (arch, slackware, ...) ?

[Anoniem: 49516]

Ksplice: RHEL/CentOS en Ubuntu desktop
Kernelcare: RHEL/CentOS 5.x, 6.x and 7.x, CloudLinux 5 & 6.x and Virtuozzo/PCS/OpenVZ 2.6.32, and Debian 6 & 7

Verder virtualiseren we alle productie servers, dus dat scheelt ook erg!

[Reactie gewijzigd door Anoniem: 49516 op 23 juli 2024 21:46]

[MAX3400]

In de enterprise-wereld is soms elke reboot er eentje teveel. Een running update is dus zeer welkom en je kan dan een reboot uitstellen tot een (veel) later tijdstip zoals een maintenance window maar ondertussen wel een nieuwe/secure kernel draaien.

[MMaster23]

Noem mij extreem verwend maar gemiddelde virtuele (en goed ingestelde fysieke) server (icm in mijn geval met 2012 r2) start in enkele seconden compleet op.. Inclusief de software die erop moet draaien..

In dit soort situaties is soms zelfs sneller dan met man.windows te werken. Onderhoud aan fysiek spul is sowieso al easy.. Merendeels draait alles virtueel danwel highly available. Dus fail over.. Patch.. Fail back.

Reboots bij patches anno 2015 op een uefi standaard? Peanuts..

[MoonWatcher]

Ik draai voor mijn werk virtuele clusters in een private cloud.
De componenten van deze clusters hangen weer met service orchistration software aan elkaar vast.
( zodat dynamisch componenten bij en afgeschakeld kunnen worden )
Met dit soort technieken kun je met weinig man kracht snel een hoop identieke omgevingen in de lucht krijgen en beheren. Inmiddels beheren we zo'n 300 van dit soort machines.

Software upgrades lopen via unattended upgrades en dit gaat perfect. Nooit issues mee, hoogstens een paar seconden hipupje bij een mysql herstart of apache restart. Maar dat ga je toch houden. Security staat bij ons hoog in het vaandel. Tot centrale layer 7 firewalls en al aan toe. Maar ik zou er een baan bij krijgen als ik voor al deze klanten reboots moet gaan inplannen bij elke kernel upgrade. De praktijk is dan ook: het gebeurd niet, of te weinig. De impact is gewoon te groot. En het is het risico niet waard.

Ik ben blij dat online patchen nu mainstream gaat worden. Het internet heeft dit hard nodig.

[MMaster23]

Impact? Van een reboot?
Qua tijd of qua complexiteit en zaken die dan kunnen omvallen?

Als men een reboot vreest omdat er dan wellicht zaken omvallen, zijn zaken niet goed ingeregeld

[CAPSLOCK2000]

In plaats van plannen kun je ook afspraken maken. Wijs voor iedere server een dag en tijdstip aan waarop ze worden gereboot. Klanten snappen ook wel dat onderhoud noodzakelijk is. Met virtuele systemen zal een reboot meestal binnen een minuut gedaan zijn. Zolang maar voorspelbaar is wanneer het gebeurt wil men daar best rekening mee houden. Als dat niet acceptabel is vraag je een vergoeding om reboots alleen te doen na coordinatie met de klant. Een systeem dat zo belangrijk is dat het ook niet een paar minuten offline kan zijn mag best iets meer kosten.
Ik reboot 90% van mijn systemen tijdens kantoortijd waarbij niet meer is afgesproken dan de dag waarop ik het doe. Ik heb zelfs Linux(!) systemen die iedere nacht worden gepatched en dan rebooten. De gebruikers zijn er dan toch niet. Technisch gezien nergens voor nodig maar dan hoef ik er ook niet over na te denken. Als er eens iets stuk gaat weet ik dat de storing in de afgelopen 24 uur is opgetreden en dat ik niet verder hoef terug te zoeken.

[goarilla]

Tot centrale layer 7 firewalls en al aan toe.

Je bedoelt zeker layer 5. Session and Presentation tellen niet .

De praktijk is dan ook: het gebeurd niet, of te weinig.

Inderdaad, wij zijn onderbemand en ondergekwalificeerd (niche universiteitsdepartement). Dus wij patchen ook niet .

[KopjeThee]

Toch leuk dat Linux wat meer trekjes krijgt van zijn verre voorouder: http://en.wikipedia.org/wiki/Multics . Dat was een systeem dat ontworpen was om zelfs geen downtime te hebben bij het vervangen van hardware

[johnkeates]

Het probleem is echter dat je als je maar 1 CPU hebt het heel lastig wordt je hardware te vervangen zonder downtime

[KopjeThee]

Maar het OS kan het!

[wowi]

Een zeer goede ontwikkeling, nu nog doorvoeren overal, dat scheelt enormveel downtime.
P.s. microsoft had dit ook al jaren geleden moeten ontwikkelen, daar blijf je ook met je systemen herstarten steeds

[Anoniem: 185331]

Inderdaad, sinds 2 weken geleden heb ik na lange tijd Windows nog eens opgestart, het gelijk weer herstarten na het updaten was echt vervelend! Ik kon natuurlijk wel die herstarten pop-up voor even uitzetten, maar dan maar voor 10 minuten of 1 uur. Je kon ook kiezen voor 4 uren, maar dat werkte niet eens!? Blijkbaar heeft Windows daar nog een bug inzitten. Dus had ik de pop-up achteraf maar moeten negeren, maar had toch het gevoel dat Windows jou steeds wou dwingen je pc te herstarten voordat je verder kon gaan.

[Loller1]

Als je een PC na lange tijd opstart, moet je niet kwaad zijn als er updates voor beschikbaar zijn, daarbij wacht Windows 2 dagen voordat het opnieuw opstart om die updates te installeren, tenzij jij dat handmatig doet.

[Anoniem: 145867]

Het voordeel bij Linux is dat je nu dus gewoon kan werken en alle updates tot diep in het OS kunnen worden doorgevoerd. Ideal! Helemaal voor de toepassing waar je Debian hebt draaien op je producten die je bij klanten hebt. Al dat gedoe om een afspraak te maken en weet ik het.. systemen plat leggen. Ik ben hier echt super blij mee. Voornamelijk omdat bepaalde hardware drivers alleen bij een bepaalde kernel en up werken. Dan moet je voor bepaalde drivers eerst het systeem plat leggen om die module werkend te krijgen bij de embedded applicatie die uitstaat bij de klant. Nu kan alles heerlijk remote. Zonder allemaal gedoe.

[Reactie gewijzigd door Anoniem: 145867 op 23 juli 2024 21:46]

[njitter]

Een beetje Geek weet zo te vinden hoe je dat tijdelijk kunt cancellen.. http://www.howtogeek.com/...utomatic-reboot-in-vista/

[johnkeates]

Ja, maar dat is symptoombestrijding en geen echte oplossing. Updates zijn niet slecht, maar behalve voor kernel upgrades mogen we toch wel in-place updates verwachten anno 2015. Hell, in Linux is dit al standaard mogelijk sinds... altijd?

[syl765]

Ik vind het altijd wel fijn om een server eens te rebooten. Wat als er toch iets niet blijkt te werken als de server een cold reboot doet. Heb je opeens na een stroom storing een server park dat niet meer boot.

Mooie techniek maar een reboot is soms helemaal niet erg.
Met security patches kan het wel voordelen hebben.
patches plaatsen zodat je beschermd bent en op een voor jou planbaar moment de reboot uitvoeren.

[Reactie gewijzigd door syl765 op 23 juli 2024 21:46]

[kdekker]

Het gaat louter om de kernel. Veel applicaties gebruiken veel meer dan alleen de kernel. Dus vervangen van dat soort files is veel lastiger. Er zijn altijd processen die bijv libc of libc++ vasthouden.

Het is al een knap stuk werk om updates uit te voeren (op de kernel zelf) zonder reboot, maar het is waarschijnlijk onvoldoende om een heel systeem bij te werken, zonder downtime. Op z'n minst moeten de applicaties plat die iets gebruiken buiten de kernel. En de kernel moet wel een zeer hoge graad van compatibiliteit bieden. Een vervangen kernel moet voor een draaiend programma hetzelfde blijven werken... Dat is al een prestatie op zich.

[sharkwouter]

Hoe zit het nu dan met AMD64?

[Anoniem: 646537]

Hoe bedoel je??

AMD64 is bekend als x64.

[sharkwouter]

Misschien voor Windows gebruikers, in de Linux kernel heet dat amd64. Er wordt echter niks over gezegt in het artiekel.

[Anoniem: 646537]

Misschien voor Windows gebruikers, in de Linux kernel heet dat amd64. Er wordt echter niks over gezegt in het artiekel.

Maak niks uit,sowieso is Linux kernel standaard 64bit ondersteunend.