Maskinen slår seg ikke av: en forespørsel er ingen strømbryter

Du trykker avslutt. Oppgaven starter, hjulet snurrer, og tre minutter senere kjører maskinen fortsatt. Til slutt trykker du stopp, og den dør umiddelbart, noe som reiser et opplagt spørsmål: hvorfor virket ikke det første når det andre åpenbart klarer det?

Dette er ikke to styrkegrader av samme handling. Det er to helt forskjellige ting.

Skillet alt henger på

Avslutning er en forespørsel. Virtualiseringslaget ber gjesten slå seg av selv, slik et trykk på strømknappen på en fysisk maskin ber et operativsystem lukke seg ryddig. Hva som skjer med forespørselen, bestemmer gjesten.

Stopp er et strømbrudd. Det tar strømmen fra den virtuelle maskinen umiddelbart, uten noen samtale. Dokumentasjonen advarer om det i klarspråk: å stoppe kan føre til tap av data, så bruk det med varsomhet.

Så snart du holder de to fra hverandre, slutter en maskin som ikke slår seg av å være gåtefull. Den nekter ikke. Ingen der inne hørte forespørselen.

Hvem som skal lytte

Det finnes to mulige lyttere, og en frisk maskin har minst én.

Operativsystemets håndtering av strømknappen. På en Linux-gjest er den normalt til stede. På et minimalt bilde, en beholderlignende enhet, eller et system som har havnet i en tidlig oppstartsfase eller et redningsskall, kan den mangle.

Gjesteagenten. Når den er slått på og faktisk kjører, gir den virtualiseringslaget en direkte kanal innover, og forespørselen går den veien.

Er agenten av og knappehåndteringen mangler eller ikke svarer, går forespørselen ut og kommer ingen steder. Virtualiseringslaget får ikke noe "nei". Det får ingenting, noe som utenfra ser nøyaktig likt ut og er grunnen til at oppgaven ser ut til å henge i stedet for å feile.

Hvis maskinene dine rutinemessig bruker for lang tid på å slå seg av, er det et bedre første trekk å sjekke om agenten faktisk virker enn å korte ned tidsgrenser.

Så tidsgrensen, så makten

Ventingen har en grense. Per gjest er standard tidsgrense for avslutning 180 sekunder; når den løper ut, stoppes maskinen med makt.

En samlet stopp av alt på en node har sitt eget budsjett: den forsøker en ryddig avslutning, venter opptil tre minutter som standard, og stopper så hardt det som fortsatt kjører.

Den ærlige beskrivelsen av en ubevoktet avslutning er altså: spør pent, vent en fast tid, trekk så ut støpselet. Trenger databasen din fire minutter på å skrive ferdig, har standardverdiene allerede bestemt at den får tre.

Hev tallet, men hopp ikke over spørsmålet

Det er fristende å behandle tidsgrensen som knappen som skal justeres. For en maskin som virkelig trenger lengre tid, er det riktig å heve den.

Men en maskin som aldri slår seg av uansett hvor lenge du venter har ikke et tidsgrenseproblem, og å gi den ti minutter betyr bare at du venter ti minutter på den samme tvungne stoppen. Finn først ut om noen lytter.

Når en avslutningsoppgave allerede har låst seg

Sitter en avslutningsoppgave fast og maskinen må ned nå, finnes det en uttrykkelig måte å stoppe den på som overstyrer den pågående avslutningsoppgaven i stedet for å stille seg i kø bak den. Den finnes nettopp fordi tilfellet med fastlåst oppgave er vanlig nok til å trenge et svar.

Bruk den vel vitende om hva den er: fortsatt et strømbrudd, med den samme advarselen festet til seg.

Tilfellet som tar folk på senga: strømbrudd

Her slutter hele teksten å være akademisk.

Et strømbruddsskript som slår av gjester før batteriene tar slutt, arver hver eneste egenskap over. Det sender forespørsler. Gjester som ikke lytter, overser dem. Tidsgrensen løper. Så blir alt som fortsatt kjører stoppet hardt, kanskje med allerede svakt batteri og kanskje alt på én gang.

To ting er verdt å sjekke før du stoler på et slikt oppsett, og begge er billige:

Svarer gjestene faktisk på en avslutningsforespørsel? Test én, med stoppeklokke, en helt vanlig ettermiddag.

Passer det samlede budsjettet i batteriet? Gjestene slås av etter tur, og tidsgrensene legger seg sammen. En rekke maskiner som bruker to minutter hver er ikke en tominutters avslutning.

En strømbruddsplan som aldri er øvd på, er en plan som blir øvd på nøyaktig én gang: i mørket, under tidspress.

Hva Atlas gjør

Atlas finner ikke opp en tredje slags avslutning. Å spørre og å kutte strømmen er de to tingene som finnes, og å late som noe annet ville vært en løgn med følger.

Det Atlas gjør, er å nekte å viske dem ut. En ødeleggende handling sier at den er ødeleggende før du bekrefter den, slik at "stopp" aldri dukker opp forkledd som en litt fastere "avslutt". Det skillet er hele emnet i denne teksten, og et panel som viser de to som nabo-knapper med lik vekt, har allerede mistet det.

Den daglige oppsummeringen bærer den andre halvdelen: en uplanlagt omstart meldes som et faktum. En maskin som ble tvangsstoppet etter en mislykket ryddig avslutning, ser neste morgen nøyaktig ut som en maskin som krasjet. Begge fortjener å bli lagt merke til.