Tenere un Mac sveglio per una sola attività VPN, non per la VPN
caffeinate mantiene una richiesta di alimentazione per il comando avvolto, nient’altro. Non può rinnovare le chiavi di un tunnel, prolungare una sessione o sopravvivere a un coperchio chiuso.
Le serve che un trasferimento finisca mentre si allontana, e il Mac che dorme è il sospettato ovvio. caffeinate può mantenere una richiesta di alimentazione esattamente per quella finestra, ed è uno strumento più stretto di quanto sembri a prima vista. Impedisce la sospensione per inattività mentre un comando gira; non tiene viva una sessione VPN e non salverà un trasferimento da credenziali che scadono a mezzanotte. Sapere dove finisce la sua portata è ciò che impedisce al guasto successivo di essere attribuito allo strato sbagliato.
Che cosa trattiene davvero la richiesta
L’utilità chiede al sistema di gestione dell’energia di tenere aperta una richiesta finché vive il processo avvolto. Quando il processo esce, la richiesta se ne va con lui. È quella durata la parte utile: non sta cambiando un’impostazione dell’intera macchina sperando di ricordarsi di annullarla dopo.
I flag selezionano richieste diverse. -i impedisce la sospensione per inattività del sistema. -d punta alla sospensione dello schermo, e -s punta alla sospensione del sistema nelle situazioni in cui il sistema lo consente. Nessuno è una promessa generale di «restare sveglio», e nessuno sblocca lo schermo o annulla la chiusura del coperchio. Scelga quello che corrisponde all’interruzione che ha davvero visto.
Questa distinzione conta quando qualcuno riferisce che il Mac «si è comunque addormentato». La domanda è quale richiesta è stata chiesta, per quanto tempo e quale evento ha causato la sospensione. La gestione dell’energia valuta diversi ingressi, e una richiesta ne copre uno.
Avvolga l’attività invece di decorare la sessione
caffeinate -i /usr/bin/ssh [email protected]
Questo mantiene la richiesta di inattività finché gira il client SSH, che è tutto il senso dell’avvolgimento invece dell’esecuzione in background. Il profilo VPN resta intatto, nessun segnale di mantenimento viene inviato, e nulla della configurazione del tunnel cambia.
Per una finestra limitata, il flag di durata è la forma onesta:
caffeinate -i -t 1800
Interrompa quell’invocazione con la sua interruzione normale quando l’attività finisce prima. Non lasci una pila di involucri in background e poi non ripulisca uccidendo ogni processo con lo stesso nome; porterà via qualcosa che voleva conservare.
La sospensione è una causa, non la causa
Impedire la sospensione per inattività rimuove un’interruzione dall’elenco. Non annulla un comando di sospensione deliberato, un coperchio chiuso, una perdita di alimentazione o una politica impostata da un amministratore. Sono decisioni separate, e aspettarsi che una richiesta a livello utente le vinca è il modo in cui le persone concludono che lo strumento non funziona.
La sospensione dello schermo e il blocco schermo sono anch’essi separati. Un Mac può restare sveglio con lo schermo spento, e può bloccarsi mentre l’attività continua. Se il requisito è uno schermo illuminato, è un altro flag; se il requisito è uno schermo sbloccato, nessun flag lo fornisce. Dica quale di questi tre esiti le serve davvero prima di scegliere un interruttore, perché non sono un solo comportamento con nomi diversi.
La sessione VPN ha il proprio orologio
Un tunnel IPsec o TLS rinnova le chiavi secondo una pianificazione concordata dagli estremi, e un server può imporre una durata massima della sessione indipendentemente dall’attività del client. Le credenziali scadono. Un collegamento di accesso può cadere per motivi che non hanno nulla a che vedere con il fatto che il portatile sia sveglio. Nulla di questo si cura di una richiesta di alimentazione.
Quindi, quando il traffico utile fallisce mentre il Mac è chiaramente sveglio, aumentare la durata non è una spiegazione né una riparazione. Legga il guasto: un errore di rinnovo delle chiavi, una scadenza dell’autenticazione e una perdita di portante appaiono diversi nel registro del tunnel, e ciascuno ha la propria correzione.
Metta la durabilità sull’host remoto
Se perdere la connessione locale sprecasse ore di lavoro, la risposta è dall’altra parte. Un multiplexer di terminale mantiene viva la sessione sul server quando SSH muore, e un sistema di job mantiene vivo il lavoro quando la sessione finisce. Nessuno dei due dipende dallo stato di alimentazione del portatile.
È un confine di guasto diverso, ed è quello che conta per i lavori lunghi. Combini i due solo quando entrambi sono veri: la macchina deve restare sveglia per la parte locale del lavoro, e la parte remota deve sopravvivere a una disconnessione. Poi verifichi riconnettendosi da un secondo terminale e controllando che il lavoro sia ancora in esecuzione.
Annoti quale richiesta ha usato e quando finisce. Una scelta operativa di breve durata va bene; una permanente senza spiegazione diventa un ticket di assistenza sei mesi dopo, quando nessuno ricorda più perché il Mac non dorma mai.