Michael ervoer een tijdje terug problemen na langere tijd wel updates, maar geen herstarts te hebben uitgevoerd; MySQL had blijkbaar een update-commando nodig. Zijn advies: herstart maar gewoon na een update, dan blijven programma’s niet te lang (als in “langere tijd na het ontvangen van updates, waarbij misschien configuratie-bestanden zijn aangepast”) draaien.
Ik ben het er deels, maar niet helemaal mee eens.
Waarom een herstart niet gaat helpen
Ik denk dat in Michaels specifieke situatie een eerdere herstart het probleem met MySQL misschien eerder aan het licht had gebracht, maar het niet had voorkomen.
Het probleem was namelijk een niet-gedraaid update-script, dat handmatig uitgevoerd moest worden. Als hij eerder had herstart, had hij dus eerder de melding over corrupte dit en dat gekregen, maar hij had het nog steeds zelf mogen oplossen. Hetzelfde was van toepassing geweest bij een nieuwere versie van software die een aanpassing in een configuratie-bestand vereist.
De werkelijke oplossing voor dit soort problemen is even saai als bewerkelijk: goed opletten wat er bij een update geïnstalleerd gaat worden, of daar grote versie-sprongen in zitten, en of daar bekende breaking changes bij komen kijken. Hoe je dat doet, wisselt een beetje per package manager:
- Zypper, de package manager van OpenSUSE, kent
zypper list-updates
voor het weergeven van aanstaande updates - Apt (te vinden op Debian en afgeleiden) heeft
apt-listchanges
- Yum en DNF (Red Had en vriendjes) hebben
yum check-update
(ofdnf check-upgrade
) - Over het algemeen zijn er ook nog commando’s voorhanden om een minimale update uit te voeren, dus alleen de hoognodige updates voor beveilingsrisico’s. Zypper heeft
patch
, DNF heeftupgrade-minimal
. Alle geïnstalleerde pakketten waar geen beveilingsproblemen in zijn gevonden, worden dan met rust gelaten.

Met die insteek is het ook ineens een stuk logischer waarom servers vaak op behoudende Linux-distro’s als Debian, CentOS en OpenSUSE Leap draaien: gedurende de levensduur van een release van zo’n distro wordt het gebruik van nieuwe, brekende versies van pakketten zoveel mogelijk uitgesloten. Daardoor blijf je niet zitten met een database-server die ineens ongepland plat gaat, want zo’n verandering komt pas met een volgende grote release (een distributie-upgrade, wordt dat meestal genoemd) mee, en kun je je er beter op voorbereiden en dingen vooraf grondig testen.
Dan nog zijn kleinere updates geen reden om de hele server te herstarten: als alleen MySQL is geüpdatet, hoef je alleen MySQL te herstarten. Apt zal daar tijdens de update - als je die handmatig uitvoert, tenminste - zal je erom vragen, op OpenSUSE kun je na de update met sudo zypper ps -s
een lijstje opvragen van alle services die een herstart kunnen gebruiken.
Wanneer een herstart wél zin heeft
Zeker op professionele serverhardware, met een hele diagnostische zang- en dansact die van een herstart een hele happening maakt, kan het een flink verschil maken of je een paar services of de hele server herstart. Er zijn maar weinig updates die echt een volledige herstart vereisen. Gelukkig kan ook daar je package manager je bij helpen.
-
Zypper geeft voor de update aan, of er een herstart nodig is. Met
zypper ps -s
zie je behalve de bijgewerkte maar nog draaiende services, ook of een herstart nodig is; in dat geval is de return-waarde ook anders -
Apt creëert een bestand
/var/run/reboot-required
als dat nodig is. -
Voor RedHat-achtigen is er
needs-restarting -r
als onderdeel van hetyum-utils
-pakket.
Soms is er een heel diepliggend stuk software geüpdatet, zoals de kernel of libc, of zijn er zoveel services te herstarten dat het :effort: wordt om dat met de hand te doen. in die gevallen, tja, dan is een herstart handig of nodig.
Een andere situatie waarin herstarts nodig zijn, zijn transactional updates, die door steeds meer speciale distro’s worden gebruikt. Een systeem als MicroOS installeert software niet “over de huidge” heen, maar in een btrfs-snapshot ernaast. Om de nieuwe software te gaan gebruiken, herstart je naar dat nieuwe snapshot. Dat heeft als voordeel, dat een update altijd in het geheel lukt óf in het geheel niet lukt, en in het laatste geval nooit een gebroken systeem achterlaat. Bovendien kun je altijd terug naar de vorige versie door simpelweg weer van een ouder snapshot te herstarten.
Voor een “unieke” server die een aantal services als enige draait is dat vanwege reboots iets minder praktisch, maar als je een slootje Docker-hosts hebt die allemaal hetzelfde zijn en ook makkelijk even uit de pool kunnen worden gehaald zonder dat de rest daar last van heeft, is het wel handig. Sowieso draait in die omgevingen de daadwerkelijke software over het algemeen in containers, waarvan de versies van benodigde software vastgelegd kan worden.
Hoe je een herstart zo snel en pijnloos mogelijk uitvoert
OK, je zit in een situatie waarin een herstart echt nodig is (en je zeker weet dat er niets stuk gaat). Hoe doe je dat zo snel mogelijk?
Het ligt voor de hand om simpelweg systemctl reboot
te gebruiken, en als je machine snel door een koude start heen gaat (bijvoorbeeld omdat het een VM is), of als het niet uitmaakt dat de machine even uit de lucht is, is dat prima. Een werkstation kun je wel een minuutje missen, en ook een server die onderdeel uitmaakt van een hele vloot kan waarschijnlijk wel door de rest worden opgevangen.
Die professionele servers waar ik het eerder over had, staan dan echter rustig een paar minuten elk hardware-onderdeel te keuren en de zin van het bestaan te overdenken, en al die tijd ligt alles, als het een enkele server is die een bepaalde service draait, stil. Voor die situaties zijn ksplice en kexec uitgevonden.
Ik heb geen ervaring met ksplice, dus ik kan er verder weinig over melden, maar kexec ken en gebruik ik wel.
Wat kexec doet is even simpel als geniaal: vanaf je draaiende kernel wordt een andere kernel gestart; iets wat normaal door je bootloader wordt gedaan. Met andere woorden, je slaat dus de hele stap BIOS (of UEFI) en bootloader over. Je gebruikt kexec in twee stappen: eerst zorg je met kexec -l
dat een specifieke kernel en initrd geladen worden, en daarna laat je het systeem met systemctl kexec
naar die kernel herstarten.
OpenSUSE maakt de eerste stap kinderlijk eenvoudig, door telkens een symlink te maken van de meest recente kernel naar /boot/vmlinuz
en de bijbehorende initrd naar /boot/initrd
. Het kexec-commando ziet er voor mij dus als volgt uit:
sudo kexec -l /boot/vmlinuz --initrd=/boot/initrd --reuse-cmdline
sudo systemctl kexec
De parameter --reuse-cmdline
zorgt ervoor dat ik niet eens hoef na te denken over wat de hele commandline van mijn laatste herstart was.
Hoe dan ook, een paar minuten wachten wordt ineens teruggebracht tot ongeveer een minuut. Win!
TL;DR
- Een herstart na een update kan zeker zin hebben, en is in sommige gevallen geen enkel probleem.
- Daarnaast is het nog steeds belangrijk om in de gaten te houden wat er met een update meekomt, zeker op een server.
- Een wat conservatievere distro ruilt “altijd de nieuwste software” in voor “vrijwel zeker een systeem zonder verrassingen” - het is afhankelijk van je gebruik wat voor jouw situatie het beste past.
- Verdiep je eens in de package manager van je distro, waarschijnlijk zitten er meer mogelijkheden en handige opties in dan je denkt!