Kartan · Del två · Maskinen · Kapitel 18 av 23

Dödmansgreppet

En kraschad körning och en körning utan något att säga såg förr likadana ut: båda var tystnad. Nu ropar en observatör när något går sönder på maskinen, och en annan slår larm när en signal uteblir, vilket är det enda larm en död maskin fortfarande kan ge. Ungefär 9 minuter · på tiominutersvägen.

Här är felet som hela det här kapitlet finns för att undanröja. Nattkörningen skickar ett meddelande till ägarens telefon bara när ett bolag behöver uppmärksamhet. De flesta nätter gör inget bolag det, och telefonen är tyst. Anta nu att körningen kraschade klockan 22:30 en tisdag och har varit död sedan dess. Telefonen är tyst. De två situationerna, "ingenting behöver dig" och "ingenting har körts på en vecka", ger exakt samma upplevelse: tystnad. Med verktygets egna ord: "en bevakning vars felläge är tystnad är en bevakning som slutar bli trodd första gången du får veta det den hårda vägen."11vss/heartbeat.py, inledningen.

Namnet, och var det kommer ifrån

Tåg har ett handtag som föraren måste hålla eller trycka ned med jämna mellanrum. Om föraren segnar ned släpps handtaget och bromsarna går på. Det kallas dödmansgrepp, och konstruktionsidén är att säkerheten inte får bero på att en signal skickas, eftersom en människa som inte kan skicka den är precis det fall som den finns för. Den måste bero på en signal som fortsätter komma, med larmet på dess uteblivande.22Wikipedia, Dead man's switch: 'Vigilance control was developed to detect this condition by requiring that the dead man's device be released momentarily and re-applied at timed intervals.' Programvaruversionen kallas dödmansgrepp (dead man's switch), och den fungerar på samma sätt: något väntar sig en regelbunden signal och slår larm när signalen inte kommer.

Två observatörer, för det finns två sorters döda

En maskin kan vara levande och trasig, eller så kan den vara död. De kräver olika observatörer, eftersom en observatör som bor på maskinen dör med den.

Observatör ett bor på maskinen

När körningen misslyckas startar schemaläggaren notifieraren från kapitel 17, som skickar till telefonen vad som stannade och de sista raderna ur loggen. Det här är den snabba observatören: den utlöses medan felet pågår, och den kan beskriva det. Dess svaghet är att den behöver att maskinen är uppe, att schemaläggaren går och att timern har utlösts. En timer som stängdes av efter en omstart startar ingenting, så ingenting misslyckas, så ingenting ropar, och det är precis det fel som mest liknar en tyst vecka.

Därför har observatör ett ett andra ben på sin egen timer: varje morgon klockan 09:30 kontrollerar ett separat jobb om en slutförd körning finns i registret och om nattimern fortfarande är aktiverad. Det körs avsiktligt på sin egen timer: "om kontrollen av körningen delade timer med körningen skulle felet som stoppade körningen stoppa kontrollen, och dödmansgreppet vore kopplat till sin egen strömförsörjning."33deploy/vss-checkin.timer, kommentar. Körningen registrerar också sin egen slutförning i en tabell, med en gräns på 72 timmar för nattkörningen och 10 dagar för veckokörningen, och en provkörning eller en körning på ett enda bolag nollställer inte klockan.

Observatör två bor utanför

Inget av det hjälper om maskinen är avstängd, nätverket ligger nere eller hela schemaläggaren har stannat. En död maskin kan inte larma om sig själv. Det enda som kan upptäcka en död maskin är något som inte finns på den: en yttre tjänst som väntar sig en signal om dagen och slår larm när signalen inte kommit före en tidsgräns.44vss/heartbeat.py: 'a dead VPS cannot page itself... Closing that needs an OUTSIDE observer — a service that expects a ping and alerts on its ABSENCE.' Det är den tomma förfrågan från framgångsutgången i kapitel 17. Den yttre tjänsten "är tyst så länge pingarna kommer i tid" och "slår larm så fort en ping inte kommer i tid", med en respitperiod efter den förväntade tiden.55Övervakningstjänstens egen dokumentation; de föreslagna inställningarna i exempelmiljöfilen är en period på en dag och sex timmars respit.

Varför frånvaro slår fel

Ett felmeddelande behöver en avsändare. Varje avsändare kan fela på ett sätt som hindrar sändningen: processen kraschade innan den nådde den raden, nätverket låg nere, maskinen var avstängd. Ett larm på frånvaro behöver ingenting från den felande sidan. Det är den enda sortens larm vars täckning omfattar fallet att det som bevakas inte längre finns. Därför ger den lyckade körningen ett ljud till den yttre observatören och inget ljud till telefonen: ljudet är inte till för ägaren, det är till för det som kommer att märka när ljudet uteblir.

Ägarens ord när det här benet lades till: "en död VPS är exakt det fall jag vill ha täckt och ingen ping lämnar data."66deploy/vss-ping-healthcheck.sh, med citat av ägaren, 2026-09-01.

Varför notifieringsadressen hålls utanför förvaret

Telefonnotiserna går via en offentlig pushtjänst där vem som helst som känner till ett ämnes namn kan posta till det. Ämnesnamnet är därför den enda hemlighet tjänsten har, och det ligger i en fil i ägarens hemkatalog som aldrig checkas in. Programmet läser det först från miljön, sedan från den filen, och skriver, loggar eller skriver aldrig ut det. Samma fil rymmer den yttre observatörens adress. Förvaret innehåller en exempelfil där båda lämnats tomma.77deploy/vss.env.example: 'THE REAL FILE IS NEVER COMMITTED: the topic is the only secret ntfy has.' vss/env.py läser miljön först, sedan filen. Ämnet är bara utgående: ingenting i projektet läser någonsin från det, så även ett läckt namn låter en utomstående bara posta brus till ägarens telefon, inte läsa något.

Vad som inte täcks, sagt i stället för antytt

• Veckoscreeningen har ingen egen yttre signal. En död veckoscreening fångas bara av morgonkontrollen.
• En maskin som är uppe, pingar och har fel. Den yttre observatören bevisar att körningen blev klar, inte att den var rätt.
• Att själva den yttre observatören ligger nere.
• Telefontunneln (kapitel 19) har ingen felnotis, av ett skäl som det kapitlet förklarar.

Ett fel som konstruktionen hittade hos sig själv

Den 2026-09-13 startade sidservern om sju gånger i rad på grund av en saknad mapp, och notifieraren skickade sju meddelanden. Vart och ett sa att ingen rapport hade skrivits för dagen, eftersom den meningen hade skrivits för nattkörningen och återanvänts för varje enhet. För en sidserver som aldrig skriver en rapport var meningen falsk. Rättelsen, registrerad som en punkt i backloggen och incheckad samma dag, ger varje enhet sin egen korrekta mening om vad dess stannande betyder.88Backlogpunkt B-13; commit 'the failure notifier says what stopped, not "no report was written" for every unit'. En notifierare som ljuger, även lite, är på väg att bli ignorerad.

Beslut

Två observatörer. En på maskinen som beskriver vad som gick sönder; en utanför som slår larm när en daglig signal uteblir. Framgångsutgången signalerar till den yttre observatören och säger ingenting till telefonen.

Varför

Tystnad måste betyda en sak. Det enda larm som täcker en död maskin är ett som ges av något som inte finns på den.

Kostnad

En andra extern tjänst, vars egna avbrott är obevakat. En signal som lämnar maskinen varje natt, hållen till en enda tom förfrågan så att ingenting om boken lämnar den med.

Källor för det här kapitlet

1. Dead man's switch, Wikipedia
   https://en.wikipedia.org/wiki/Dead_man%27s_switch
2. Healthchecks.io-dokumentationen (larm vid saknad ping)
   https://healthchecks.io/docs/
3. Hjärtslagsmodulen och enheterna — läst ur det här repot: vss/heartbeat.py; deploy/vss-checkin.timer; deploy/vss-ping-healthcheck.sh; deploy/vss-notify-failure.sh; deploy/vss.env.example; reference/BACKLOG.md B-13

Den långsamma vägen, gjord uthärdlig. Byggd 2026-09-13 ur repot som det såg ut den dagen. BOLAG A och BOLAG B är påhittade; inget bolag, ingen kurs och inget innehav förekommer på den här sajten. Inte finansiell rådgivning: en privatinvesterares metod, delad som den är.