Dê a um pequeno job agendado um limite claro.

Defina uma peça finita de trabalho

Imagine uma ferramenta pessoal que reconstrói um pequeno resumo diário a partir de seus registros existentes. A tarefa lê um conjunto limitado de dados, prepara um resumo substituto e termina. Não é um servidor web e não deve continuar em execução entre inícios agendados. Anote a entrada, o destino, a duração esperada e o que conta como sucesso antes de adicionar um timer.

O exemplo assume um host Linux com systemd e util-linux flock, acesso de administrador, e uma conta e grupo sem privilégios existentes chamados fieldjob. Seu script de tarefa revisado fica em /opt/field-jobs/build-summary e é executado em primeiro plano. Um administrador é proprietário desse script; a conta da tarefa pode lê-lo e executá-lo, mas não pode reescrever seu código. Verifique os caminhos executáveis na sua distribuição. Estes são modelos, não um serviço de agendamento OffVPS instalado.

O script deve reportar falha com um status de saída diferente de zero. Para arquivos de substituição, projete-o para preparar e verificar um resultado temporário antes de publicá-lo. Para trabalho em banco de dados, use o mecanismo de transação ou deduplicação do banco de dados. Um bloqueio sozinho não pode tornar uma tarefa parcialmente concluída segura de repetir.

Escolha um fuso horário e uma política de execução perdida

Nosso resumo é útil uma vez por dia às 02:15 UTC. Use um fuso explícito para que o fuso horário local da máquina não seja uma dependência invisível. UTC evita mudanças sazonais de relógio neste exemplo; uma tarefa de negócios vinculada ao horário civil local precisa de um fuso horário nomeado e uma revisão de seu comportamento de horário de verão. A referência de tempo do systemd descreve expressões de calendário.

Salve este modelo como /etc/systemd/system/field-summary.timer no VPS pretendido após revisar os nomes:

[Unit]
Description=Daily personal-tool summary

[Timer]
OnCalendar=*-*-* 02:15:00 UTC
Persistent=true
Unit=field-summary.service

[Install]
WantedBy=timers.target

Persistent=true solicita uma ativação de recuperação após um período inativo se um evento de calendário foi perdido. Ele não repete uma execução separada para cada dia perdido. Um timer também não inicia outra instância do mesmo serviço enquanto esse serviço está ativo. Esses comportamentos, e a precisão do agendamento, são cobertos pela referência do timer. Decida se um resumo tardio é útil antes de habilitar a recuperação.

Defina o usuário do serviço, o diretório de estado e o bloqueio

O correspondente /etc/systemd/system/field-summary.service descreve o trabalho:

[Unit]
Description=Build the personal-tool summary

[Service]
Type=oneshot
User=fieldjob
Group=fieldjob
WorkingDirectory=/opt/field-jobs
StateDirectory=field-summary
StateDirectoryMode=0700
UMask=0077
ExecStart=/usr/bin/flock --nonblock --conflict-exit-code 75 /var/lib/field-summary/job.lock /opt/field-jobs/build-summary
TimeoutStartSec=5min
StandardOutput=journal
StandardError=journal

Type=oneshot adequa-se a um comando que termina; um timeout de inicialização explícito limita este exemplo. Não adicione RemainAfterExit=yes a um serviço que deve se tornar inativo após cada execução. Consulte semântica de serviço do systemd. Defina um timeout a partir da carga de trabalho, e torne a interrupção segura em vez de assumir que cinco minutos servem para toda tarefa.

Para este serviço de sistema, StateDirectory cria o diretório nomeado sob /var/lib com propriedade do serviço. O diretório de trabalho, usuário, permissões e destinos de saída são explícitos; o script deve usar caminhos absolutos para suas próprias ferramentas e dados. As regras de ambiente e diretório estão documentadas em referência de execução do systemd. Não coloque valores secretos em argumentos de linha de comando nem os registre em log.

O wrapper não bloqueante flock sai com código 75 quando outra invocação cooperante mantém este bloqueio. Deixamos isso deliberadamente como uma falha visível que precisa de revisão, em vez de tratar um resumo ignorado como trabalho concluído. Todas as invocações manuais devem usar o mesmo wrapper e caminho de bloqueio. Não exclua um arquivo de bloqueio para liberar uma tarefa em execução: um novo arquivo pode criar um bloqueio separado. Este é um padrão de sistema de arquivos local, não um bloqueio distribuído entre instâncias de VPS. Consulte o manual do flock upstream.

Verifique os arquivos, depois tente uma execução controlada

Use um conjunto de dados descartável com e-mail de saída, pagamentos e outros efeitos colaterais desabilitados para a primeira execução. Antes da ativação, inspecione o agendamento analisado e os arquivos de unidade nesse host de teste:

systemd-analyze calendar '*-*-* 02:15:00 UTC'
systemd-analyze verify /etc/systemd/system/field-summary.service /etc/systemd/system/field-summary.timer

Essas verificações podem detectar erros de unidade e de agendamento; elas não podem estabelecer que seu script produz um resumo correto. A referência do systemd-analyze explica seu escopo. Após corrigir os erros, carregue os arquivos revisados e inicie explicitamente a tarefa de teste:

sudo systemctl daemon-reload &&
  sudo systemctl start field-summary.service
systemctl status field-summary.service --no-pager
sudo journalctl -u field-summary.service --since "10 minutes ago" --no-pager

Espere uma invocação bem-sucedida finita e um artefato de saída verificado; um oneshot bem-sucedido pode aparecer inativo depois. Inspecione o resultado em si, incluindo o comportamento com entrada vazia. Faça uma execução apenas de teste deliberadamente lenta, invoque o mesmo comando bloqueado duas vezes no conjunto de dados de teste e verifique se a segunda invocação relata contenção de lock sem gravar um resultado concorrente.

Habilite o agendamento somente após verificar sua saída

sudo systemctl enable --now field-summary.timer
systemctl list-timers field-summary.timer --all

Verifique o próximo horário agendado e depois revise o primeiro resultado agendado. Mantenha o horário de início, o horário de término, a contagem de itens processados e o resultado nos logs do script. A ausência de um registro de sucesso é um motivo para inspecionar, não prova de que o job foi executado. Consulte os comandos de timer e ativação do systemctl.

Para pausar inícios futuros, use sudo systemctl disable --now field-summary.timer. Isso não encerra um serviço já em execução. Se a interrupção for necessária, primeiro estabeleça se a gravação atual pode ser interrompida com segurança. À medida que o trabalho cresce, revise duração, tentativas e limites de API externa; várias máquinas exigem coordenação compartilhada. Continue com o cenário de ferramentas pessoais e um exercício de restauração para os dados que esta automação mantém.