Lleva una línea de crontab a un temporizador de systemd.

Toma una sola línea de crontab —los cinco campos de tiempo más el comando— y genera una configuración equivalente en systemd: una unidad .timer con una expresión OnCalendar= que coincide con tu programación, y una unidad .service que ejecuta tu comando. También enumera notas de migración que señalan cualquier cosa que systemd maneje de forma distinta, como el directorio de trabajo implícito o el entorno. Todo se calcula en tu navegador.

No. El conversor se ejecuta 100 % del lado del cliente. Tu línea de cron y tu comando se analizan y se traducen en la pestaña de tu navegador: nada se sube a un servidor y no hay cuenta ni registro. Es seguro pegar comandos y rutas internas.

Un conjunto de campos de crontab se reescribe en la sintaxis de calendario OnCalendar= de systemd; por ejemplo, «0 3 * * *» se convierte en «*-*-* 03:00:00» (a diario a las 03:00). Las listas, los rangos y los valores de paso se asignan a sus equivalentes en OnCalendar, y los @macros habituales como @daily y @hourly se asignan a sus formas canónicas de temporizador. Tras instalar el temporizador, puedes confirmar las próximas ejecuciones con «systemctl list-timers».

Los temporizadores te dan registro estructurado a través del journal (journalctl -u your.service), ordenamiento de dependencias, límites de recursos, reintento automático y programación precisa frente a monotónica, además de Persistent=true para que una ejecución perdida pueda dispararse en el siguiente arranque. Son la primitiva de programación nativa en las distribuciones Linux modernas con systemd, donde a menudo ni siquiera está instalado el crond por usuario.

Unos pocos comportamientos de cron no tienen un análogo directo en OnCalendar= y en su lugar aparecen como notas de migración: extensiones de cron no estándar o propias del proveedor, el correo de salida MAILTO (usa journald o un manejador OnFailure=) y las asignaciones de entorno por línea (muévelas a Environment= o a un EnvironmentFile= en el .service). El conversor las señala para que nada cambie de significado en silencio.

No. Esta es una utilidad independiente y comunitaria, y no está afiliada ni respaldada por el proyecto systemd ni por ninguna implementación de cron. Modela los formatos estándar de crontab y de unidades de systemd por familiaridad y los nombra solo para describir lo que convierte.

@reboot no tiene equivalente en OnCalendar= y se asigna a OnBootSec=1min en la sección [Timer], de modo que el trabajo se dispara una vez poco después de cada arranque. @hourly se expande a OnCalendar=*-*-* *:00:00, @daily a OnCalendar=*-*-* 00:00:00, @weekly a OnCalendar=Sun *-*-* 00:00:00, @monthly a OnCalendar=*-*-01 00:00:00, y @yearly a OnCalendar=*-01-01 00:00:00. El conversor maneja todos estos automáticamente y anota el caso especial de @reboot.

Añade Persistent=true a la sección [Timer] junto a tu línea OnCalendar=. systemd registra en disco la hora del último disparo y, si la hora programada pasó mientras la máquina estaba apagada, ejecuta el trabajo de inmediato en el siguiente arranque. El conversor siempre incluye Persistent=true en la unidad .timer generada, así que este comportamiento está activado por defecto.

Para trabajos de todo el sistema, coloca ambas unidades en /etc/systemd/system/, luego ejecuta sudo systemctl daemon-reload y sudo systemctl enable --now yourjob.timer. Habilita la unidad .timer —no el .service directamente—, ya que el temporizador es lo que controla la programación. Para trabajos por usuario, colócalas en ~/.config/systemd/user/ y usa systemctl --user enable --now yourjob.timer en su lugar.

Ejecuta systemd-analyze calendar «<expression>» para validar la sintaxis y ver cuándo transcurrirá la expresión por próxima vez; por ejemplo, systemd-analyze calendar «*-*-* 03:00:00». Una vez instalado el temporizador, systemctl list-timers muestra cada temporizador activo con sus horas de última y próxima ejecución, y journalctl -u yourjob.service transmite la salida del trabajo.