As duas expressões parecem uma manhã de quarta-feira, e só uma delas significa uma vez. 0 10 * * 3 dispara às 10:00 de quarta-feira; * 10 * * 3 dispara em cada minuto da décima hora, sessenta oportunidades de iniciar o mesmo túnel. Se o comando é um lançador que não verifica uma sessão existente, a segunda versão não é um erro de agendamento, é um ciclo que produz proprietários concorrentes. Leia o campo dos minutos antes de qualquer outra coisa.

Os cinco campos são minuto, hora, dia do mês, mês e dia da semana, nessa ordem, e um asterisco no primeiro significa todos os minutos.

O campo dos minutos decide quantas vezes

O número inicial é o minuto, portanto 0 10 * * 3 é o primeiro minuto da décima hora de quarta-feira. Substituí-lo por um asterisco mantém a hora e o dia e retira a propriedade de uma só vez, o que produz sessenta correspondências. O cron não elimina duplicados: cada correspondência volta a lançar o comando. Isto não é uma subtileza sobre o cron, é semântica de campos, e vale a pena ler a referência do agendador instalado porque a ordem dos campos e a coluna opcional de nome de utilizador diferem entre o crontab de utilizador e o do sistema.

Teste com um comando inofensivo que registe o seu próprio timestamp durante um dia. Uma linha no registo é um agendamento; sessenta linhas numa hora é uma lição.

O que um segundo lançamento faz ao primeiro

Um lançador bem comportado percebe que a ligação já está ativa e não faz nada. Uma invocação direta de openvpn não: cria outro processo, outra tentativa de ligar um dispositivo ou uma porta, e outro conjunto de rotas a competir pelos mesmos destinos. No NetworkManager, os pedidos de ativação repetidos para uma ligação são normalmente idempotentes, e é exatamente por isso que o problema fica oculto até alguém usar um comando diferente. O agendamento deve perguntar ao proprietário que já gere o túnel.

Depois decida o que significa um pedido enquanto a ligação está a ser estabelecida. Nem a ativação duplicada nem uma fila de arranques pendentes são obviamente corretas; escolha uma e faça o lançador implementá-la, em vez de deixar o agendador decidir por acidente.

Conte os campos antes do comando

Os crontabs de utilizador e de sistema diferem quanto à existência de uma coluna de nome de utilizador antes do comando. Uma entrada copiada entre eles ou corre com a conta errada ou passa o nome de utilizador como primeira palavra do comando. Verifique a referência instalada em vez de um guia, e conte os campos na sua própria linha. Uma entrada de cinco campos com uma sexta palavra antes do comando é um crontab de sistema; a mesma linha num crontab de utilizador tenta executar essa palavra como programa.

A identidade de execução transporta o ambiente consigo. Uma tarefa de cron não herda um porta-chaves desbloqueado, um pedido interativo de palavra-passe nem o diretório de trabalho onde testou.

Espere pela prontidão, não pelo relógio

Um lançamento bem-sucedido não é um túnel a funcionar. O cliente pode ainda estar a resolver o seu endpoint, a autenticar-se ou a instalar rotas quando a tarefa termina. Qualquer tarefa dependente deve esperar pelo recurso protegido de que realmente precisa, com um tempo limite e uma falha registada, em vez de um número fixo de segundos. Essa distinção separa um agendamento que funciona quase sempre de um que falha em silêncio na manhã atarefada.

Se for necessária MFA interativa a essa hora, a tarefa pode pedir a atenção de uma pessoa mas não pode fornecer a resposta. Mantenha esse caso explícito em vez de incorporar uma palavra-passe reutilizável ou repetir para sempre.

Para uma ativação genuinamente única, use o mecanismo de execução única suportado. Uma regra recorrente que tem de ser recordada e removida é um futuro lançamento duplicado.

Artigos relacionados