Håll en Mac vaken för en VPN-uppgift, inte för VPN:en

Du behöver att en överföring blir klar medan du går bort, och att Macen sover är den uppenbara misstänkta. caffeinate kan hålla ett energianspråk just för det fönstret, och det är ett smalare verktyg än det först verkar. Det förhindrar inaktiv sömn medan ett kommando körs; det håller inte en VPN-session vid liv och det räddar inte en överföring från en autentiseringsuppgift som går ut vid midnatt. Att veta var dess räckvidd slutar är det som hindrar nästa fel från att läggas på fel lager.

Vad anspråket egentligen håller

Verktyget ber energihanteringssystemet att hålla ett anspråk öppet så länge den omslutna processen lever. När processen avslutas följer anspråket med. Den livstiden är den användbara delen: du slår inte om en maskinvid inställning och hoppas komma ihåg att ångra den senare.

Flaggorna väljer olika anspråk. -i förhindrar inaktiv systemsömn. -d riktar sig mot skärmsömn, och -s riktar sig mot systemsömn i de situationer där systemet tillåter det. Ingen av dem är ett heltäckande löfte att «hålla sig vaken», och ingen av dem låser upp skärmen eller besegrar ett stängt lock. Välj den som matchar det avbrott du faktiskt såg.

Den skillnaden spelar roll när någon rapporterar att Macen «ändå somnade». Frågan är vilket anspråk som begärdes, hur länge och vilken händelse som orsakade sömnen. Energihantering väger flera ingångar, och ett anspråk täcker en av dem.

Slå in uppgiften i stället för att dekorera sessionen

caffeinate -i /usr/bin/ssh [email protected]

Detta håller anspråket mot inaktiv sömn så länge SSH-klienten körs, och det är hela poängen med att slå in i stället för att lägga i bakgrunden. VPN-profilen är orörd, ingen keepalive skickas och ingenting i tunnelns konfiguration ändras.

För ett begränsat fönster är varaktighetsflaggan den ärliga formen:

caffeinate -i -t 1800

Stoppa det anropet med dess normala avbrott när uppgiften blir klar tidigare. Lämna inte en stapel omslag i bakgrunden och städa inte senare genom att döda varje process med samma namn; du tar då bort något du ville behålla.

Sömn är en orsak, inte orsaken

Att förhindra inaktiv sömn tar bort ett avbrott från listan. Det åsidosätter inte ett avsiktligt sömnkommando, ett stängt lock, strömavbrott eller en policy som en administratör har satt. Det är separata beslut, och att förvänta sig att ett anspråk på användarnivå ska vinna över dem är precis hur folk drar slutsatsen att verktyget inte fungerar.

Skärmsömn och skärmlås är också separata. En Mac kan vara vaken med skärmen avstängd, och den kan låsas medan uppgiften fortsätter. Om kravet är en upplyst skärm är det en annan flagga; om kravet är en upplåst skärm ger ingen flagga det. Säg vilket av dessa tre utfall du faktiskt behöver innan du väljer en växel, eftersom de inte är ett beteende under olika namn.

VPN-sessionen har sin egen klocka

En IPsec- eller TLS-tunnel förnyar nycklar enligt ett schema som ändpunkterna kommit överens om, och en server kan tvinga fram en maximal sessionslivstid oavsett klientaktivitet. Autentiseringsuppgifter går ut. En åtkomstlänk kan falla av skäl som inte har något med att datorn är vaken att göra. Inget av detta bryr sig om ett energianspråk.

Så när nyttig trafik misslyckas medan Macen uppenbart är vaken är ökad varaktighet varken en förklaring eller en reparation. Läs felet: ett nyckelförnyelsefel, ett utgånget autentiseringstillstånd och en tappad bärvåg ser olika ut i tunnelloggen, och var och en har sin egen åtgärd.

Lägg varaktigheten på fjärrvärden

Om förlust av den lokala anslutningen skulle slösa bort timmar av arbete finns svaret på andra sidan. En terminalmultiplexer håller sessionen vid liv på servern när SSH dör, och ett jobbsystem håller arbetet vid liv när sessionen tar slut. Ingen av dem beror på datorns energitillstånd.

Det är en annan felgräns, och det är den som spelar roll för långa jobb. Kombinera de två bara när båda är sanna: maskinen måste förbli vaken för den lokala delen av arbetet, och fjärrdelen måste överleva en frånkoppling. Verifiera sedan genom att återansluta från en andra terminal och kontrollera att jobbet fortfarande körs.

Skriv ned vilket anspråk du använde och när det slutar. Ett kortvarigt operativt val är okej; ett oförklarat permanent blir ett supportärende sex månader senare när ingen minns varför Macen aldrig sover.