Uma tarefa agendada que correu sem a VPN parece bem

O estado da tarefa diz sucesso, o registo mostra uma execução concluída, e os dados estão desatualizados ou ausentes. Essa combinação costuma significar que a tarefa agendada arrancou sem o caminho de que precisava, e que algo mais abaixo engoliu a falha. Uma agenda que dispara a horas não diz nada sobre se a rede estava pronta. A lacuna entre esses dois factos é onde vive esta falha.

A admissão pertence à execução, não à existência de um ficheiro cron.

Uma execução verde não é uma tarefa concluída

Um agendador regista que um processo arrancou e mais tarde saiu; não faz ideia se esse processo chegou ao recurso para o qual existe. Um script que trata uma ligação falhada como um resultado vazio, ou que apanha um erro e sai com zero, parecerá saudável para sempre. O sintoma não é um estado vermelho; é um estado plausível ligado a trabalho em falta.

Nomeie o que a execução realmente precisa antes de decidir como a verificar. Uma cópia de segurança pode precisar de DNS privado e de um endpoint autenticado, não apenas de um processo de túnel.

Verifique a ligação, não o nome da interface

Uma interface chamada tun0 pode existir sem a sessão que importa, e outra ligação pode possuir esse nome. Verifique o objeto concreto de que a tarefa depende: uma identidade de perfil, uma instância de serviço ou uma pequena operação aprovada contra o recurso. Mantenha a verificação limitada no tempo e mantenha as credenciais fora dos argumentos do processo e dos registos de diagnóstico.

Defina também o resultado da desconexão. Um salto comum, uma nova tentativa dentro de uma janela curta e um prazo perdido visível ao operador são três respostas diferentes, e uma agenda recorrente não escolhe entre elas.

Saltos e falhas são resultados diferentes

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

Numa implementação systemd, ExecCondition= executa esse verificador antes da carga de trabalho. O seu comportamento de saída é específico: zero continua, os códigos de um a 254 saltam os restantes comandos de arranque sem marcar a unidade como falhada, e 255 ou uma terminação anómala fazem-na falhar. Isso dá três sinais distintos, úteis apenas se o contrato do verificador for deliberadamente mapeado para eles. As definições que redefinem o sucesso podem mudar o quadro, por isso documente o mapeamento.

É o registo dos saltos que torna o desenho honesto. Uma execução saltada que não aparece em lado nenhum é indistinguível de uma execução que teve sucesso, e tratar cada erro do verificador como um salto silencioso esconde indefinidamente uma implementação avariada.

Proteja toda a execução, não só o arranque

Uma verificação de prontidão observa o mundo antes do lançamento; não vigia cada socket depois. Quando um caminho direto nunca é aceitável para esta tarefa, anexe uma política de saída aprovada aplicada continuamente e que cubra DNS, IPv6 e o próprio transporte do túnel. Alternar o estado global de IPv6 do anfitrião não substitui uma política limitada à tarefa.

Decida se um novo evento pode sobrepor-se a uma tarefa ainda em curso, mantenha essa regra com o dono da carga de trabalho, e torne a nova tentativa segura para a operação de dados. Parar uma tarefa na desconexão limita o trabalho sem garantir nada sobre o tráfego de reserva.

Aceite o fluxo de trabalho em três casos: caminho pronto, caminho indisponível e perda a meio da execução. Qualquer coisa menos testa a agenda, não a tarefa.