Unha tarefa programada que se executou sen a VPN parece correcta

O estado da tarefa di éxito, o rexistro mostra unha execución completada e os datos están obsoletos ou ausentes. Esa combinación adoita significar que a tarefa programada arrincou sen a ruta que necesitaba, e que algo máis abaixo tragou o fallo. Unha programación que se dispara a tempo non di nada sobre se a rede estaba lista. A fenda entre eses dous feitos é onde vive este fallo.

A admisión pertence á execución, non á existencia dun ficheiro cron.

Unha execución verde non é unha tarefa completada

Un planificador anota que un proceso arrincou e logo saíu; non ten idea de se ese proceso chegou ao recurso para o que existe. Un script que trata unha conexión fallida como un resultado baleiro, ou que captura un erro e sae con cero, parecerá san para sempre. O síntoma non é un estado vermello; é un estado plausible pegado a traballo ausente.

Nomee o que a execución necesita realmente antes de decidir como comprobalo. Unha copia de seguridade pode necesitar DNS privado e un extremo autenticado, non só un proceso de túnel.

Comprobe a conexión, non o nome da interface

Unha interface chamada tun0 pode existir sen a sesión que importa, e outra conexión pode posuír ese nome. Comprobe o obxecto concreto do que depende a tarefa: unha identidade de perfil, unha instancia de servizo ou unha pequena operación aprobada contra o recurso. Manteña a comprobación limitada no tempo e manteña as credenciais fóra dos argumentos do proceso e dos rexistros de diagnóstico.

Defina tamén o resultado desconectado. Un salto ordinario, un reintento dentro dunha ventá curta e un prazo incumprido visible para o operador son tres respostas distintas, e unha programación recorrente non escolle entre elas.

Os saltos e os fallos son resultados distintos

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

Nun despregamento systemd, ExecCondition= executa ese comprobador antes da carga de traballo. O seu comportamento de saída é específico: cero continúa, os códigos do un ao 254 saltan as ordes de arrinque restantes sen marcar a unidade como fallida, e 255 ou unha terminación anormal fan que falla. Iso dá tres sinais distintos, útiles só se o contrato do comprobador se asigna deliberadamente a eles. Os axustes que redefinen o éxito poden cambiar a imaxe, así que documente a asignación.

Rexistrar os saltos é o que fai honesto o deseño. Unha execución saltada que non aparece en ningún sitio é indistinguible dunha execución que tivo éxito, e tratar cada erro do comprobador como un salto silencioso oculta un despregamento roto indefinidamente.

Protexa toda a execución, non só o inicio

Unha comprobación de preparación observa o mundo antes do lanzamento; non vixía cada socket despois. Cando unha ruta directa nunca é aceptable para esta tarefa, adxunte unha política de saída aprobada que se aplique de forma continua e cubra DNS, IPv6 e o propio transporte do túnel. Alternar o estado global de IPv6 do host non substitúe unha política limitada á tarefa.

Decida se un evento novo pode solaparse cunha tarefa que aínda se executa, manteña esa regra co propietario da carga de traballo e faga seguro o reintento para a operación de datos. Deter unha tarefa ao desconectarse limita o traballo sen garantir nada sobre o tráfico de reserva.

Acepte o fluxo de traballo en tres casos: ruta lista, ruta non dispoñible e perda durante a execución. Calquera cousa menos proba a programación, non a tarefa.