Migre uma linha de crontab para um temporizador do systemd.

Ele pega uma única linha de crontab — os cinco campos de tempo mais o comando — e gera uma configuração equivalente no systemd: uma unidade .timer com uma expressão OnCalendar= que corresponde ao seu agendamento, e uma unidade .service que executa o seu comando. Ele também lista notas de migração que apontam qualquer coisa que o systemd trata de forma diferente, como o diretório de trabalho implícito ou o ambiente. Tudo é calculado no seu navegador.

Não. O conversor roda 100% no lado do cliente. Sua linha de cron e seu comando são analisados e traduzidos na aba do seu navegador: nada é enviado para um servidor, e não há conta nem cadastro. É seguro colar comandos e caminhos internos.

Um conjunto de campos de crontab é reescrito na sintaxe de calendário OnCalendar= do systemd — por exemplo, “0 3 * * *” vira “*-*-* 03:00:00” (diariamente às 03:00). Listas, intervalos e valores de passo são mapeados para os seus equivalentes em OnCalendar, e os @macros comuns como @daily e @hourly são mapeados para as suas formas canônicas de temporizador. Depois de instalar o temporizador, você pode confirmar as próximas execuções com “systemctl list-timers”.

Os temporizadores oferecem registro estruturado através do journal (journalctl -u your.service), ordenação de dependências, limites de recursos, repetição automática e agendamento preciso versus monotônico, além de Persistent=true para que uma execução perdida possa ser disparada na próxima inicialização. Eles são a primitiva de agendamento nativa nas distribuições Linux modernas com systemd, onde muitas vezes o crond por usuário nem sequer está instalado.

Alguns comportamentos do cron não têm um equivalente direto em OnCalendar= e, em vez disso, aparecem como notas de migração — extensões de cron não padronizadas ou específicas do fornecedor, o envio de e-mail da saída via MAILTO (use o journald ou um manipulador OnFailure=) e as atribuições de ambiente por linha (mova-as para Environment= ou para um EnvironmentFile= no .service). O conversor sinaliza esses casos para que nada mude de significado silenciosamente.

Não. Este é um utilitário independente e comunitário, e não é afiliado nem endossado pelo projeto systemd ou por qualquer implementação de cron. Ele modela os formatos padrão de crontab e de unidades do systemd por familiaridade e os nomeia apenas para descrever o que converte.

@reboot não tem equivalente em OnCalendar= e é mapeado para OnBootSec=1min na seção [Timer], de modo que o trabalho é disparado uma vez logo após cada inicialização. @hourly se expande para OnCalendar=*-*-* *:00:00, @daily para OnCalendar=*-*-* 00:00:00, @weekly para OnCalendar=Sun *-*-* 00:00:00, @monthly para OnCalendar=*-*-01 00:00:00, e @yearly para OnCalendar=*-01-01 00:00:00. O conversor trata todos esses casos automaticamente e anota o caso especial do @reboot.

Adicione Persistent=true à seção [Timer] junto da sua linha OnCalendar=. O systemd registra em disco o horário do último disparo e, se o horário agendado passou enquanto a máquina estava desligada, executa o trabalho imediatamente na próxima inicialização. O conversor sempre inclui Persistent=true na unidade .timer gerada, então esse comportamento já vem ativado por padrão.

Para trabalhos de todo o sistema, coloque ambas as unidades em /etc/systemd/system/, depois execute sudo systemctl daemon-reload e sudo systemctl enable --now yourjob.timer. Habilite a unidade .timer — não o .service diretamente —, já que o temporizador é o que controla o agendamento. Para trabalhos por usuário, coloque-as em ~/.config/systemd/user/ e use systemctl --user enable --now yourjob.timer no lugar.

Execute systemd-analyze calendar “<expression>” para validar a sintaxe e ver quando a expressão vai ocorrer da próxima vez — por exemplo, systemd-analyze calendar “*-*-* 03:00:00”. Depois que o temporizador estiver instalado, systemctl list-timers mostra cada temporizador ativo com seus horários de última e próxima execução, e journalctl -u yourjob.service transmite a saída do trabalho.