Garder un Mac éveillé pour une seule tâche VPN, pas pour le VPN

Vous avez besoin qu’un transfert se termine pendant que vous vous absentez, et le Mac endormi est le suspect évident. caffeinate peut maintenir une demande d’alimentation exactement pour cette fenêtre, et c’est un outil plus étroit qu’il n’y paraît au premier abord. Il empêche la veille d’inactivité pendant qu’une commande s’exécute ; il ne maintient pas une session VPN en vie et ne sauvera pas un transfert face à des identifiants qui expirent à minuit. Savoir où son emprise s’arrête est ce qui empêche la panne suivante d’être imputée à la mauvaise couche.

Ce que la demande retient réellement

L’utilitaire demande au système de gestion de l’énergie de garder une demande ouverte tant que le processus enveloppé vit. Quand le processus sort, la demande s’en va avec lui. C’est cette durée de vie qui est utile : vous ne basculez pas un réglage pour toute la machine en espérant vous souvenir de l’annuler plus tard.

Les options sélectionnent des demandes différentes. -i empêche la veille d’inactivité du système. -d cible la veille de l’écran, et -s cible la veille du système dans les situations où le système l’autorise. Aucune n’est une promesse générale de « rester éveillé », et aucune ne déverrouille l’écran ni ne défait la fermeture du capot. Choisissez celle qui correspond à l’interruption que vous avez réellement vue.

Cette distinction compte quand quelqu’un signale que le Mac « s’est quand même endormi ». La question est de savoir quelle demande a été faite, pour combien de temps, et quel événement a causé la veille. La gestion de l’énergie évalue plusieurs entrées, et une demande en couvre une.

Enveloppez la tâche au lieu de décorer la session

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

Cela maintient la demande d’inactivité tant que le client SSH tourne, ce qui est tout l’intérêt de l’enveloppement plutôt que de la mise en arrière-plan. Le profil VPN reste intact, aucun signal de maintien n’est envoyé, et rien dans la configuration du tunnel ne change.

Pour une fenêtre bornée, l’option de durée est la forme honnête :

caffeinate -i -t 1800

Arrêtez cette invocation avec son interruption normale quand la tâche se termine plus tôt. Ne laissez pas une pile d’enveloppes en arrière-plan et ne nettoyez pas plus tard en tuant tous les processus du même nom ; vous emporterez quelque chose que vous vouliez garder.

La veille est une cause, pas la cause

Empêcher la veille d’inactivité retire une interruption de la liste. Elle n’annule pas une commande de veille délibérée, un capot fermé, une coupure d’alimentation ou une politique définie par un administrateur. Ce sont des décisions distinctes, et attendre d’une demande au niveau utilisateur qu’elle les gagne, c’est ainsi que les gens concluent que l’outil ne fonctionne pas.

La veille de l’écran et le verrouillage de l’écran sont aussi distincts. Un Mac peut rester éveillé avec l’écran éteint, et il peut se verrouiller pendant que la tâche continue. Si l’exigence est un écran allumé, c’est une autre option ; si l’exigence est un écran déverrouillé, aucune option ne la fournit. Dites lequel de ces trois résultats vous voulez vraiment avant de choisir un commutateur, car ce ne sont pas un seul comportement sous des noms différents.

La session VPN a sa propre horloge

Un tunnel IPsec ou TLS renouvelle ses clés selon un calendrier convenu par les extrémités, et un serveur peut imposer une durée de vie maximale de session indépendamment de l’activité du client. Les identifiants expirent. Une liaison d’accès peut tomber pour des raisons qui n’ont rien à voir avec le fait que l’ordinateur portable soit éveillé. Rien de tout cela ne se soucie d’une demande d’alimentation.

Ainsi, quand le trafic utile échoue alors que le Mac est manifestement éveillé, augmenter la durée n’est ni une explication ni une réparation. Lisez la panne : une erreur de renouvellement de clés, une expiration d’authentification et une perte de porteuse se présentent différemment dans le journal du tunnel, et chacune a son propre correctif.

Placez la durabilité sur l’hôte distant

Si perdre la connexion locale gaspillait des heures de travail, la réponse est de l’autre côté. Un multiplexeur de terminal garde la session vivante sur le serveur quand SSH meurt, et un système de tâches garde le travail vivant quand la session se termine. Ni l’un ni l’autre ne dépend de l’état d’alimentation de l’ordinateur portable.

C’est une autre frontière de panne, et c’est celle qui compte pour les tâches longues. Combinez les deux seulement quand les deux sont vraies : la machine doit rester éveillée pour la partie locale du travail, et la partie distante doit survivre à une déconnexion. Vérifiez ensuite en vous reconnectant depuis un second terminal et en constatant que la tâche tourne encore.

Notez quelle demande vous avez utilisée et quand elle se termine. Un choix opérationnel de courte durée est acceptable ; un choix permanent inexpliqué devient un ticket de support six mois plus tard, quand plus personne ne se souvient pourquoi le Mac ne dort jamais.