Cómo ejecutar un cron job cada 30 segundos o menos

Una línea de crontab se ejecuta como máximo una vez por minuto: la expresión no tiene un campo para los segundos. Para ejecutar un job más seguido hay dos caminos: varias ejecuciones dentro de cada minuto, desde el crontab, o un timer de systemd, que sí tiene segundos.

Cada 30 segundos, con dos líneas

* * * * * /ruta/al/job.sh
* * * * * sleep 30; /ruta/al/job.sh

La primera línea se ejecuta al comienzo de cada minuto, y la segunda espera 30 segundos antes de ejecutarse. Cron inicia las dos al mismo tiempo, así que no dependen una de la otra.

Cada 10 segundos, con un loop

* * * * * for i in 0 1 2 3 4 5; do /ruta/al/job.sh & sleep 10; done

El loop inicia el job seis veces por minuto, cada 10 segundos. El & inicia cada ejecución sin esperar a que termine la anterior, así que la duración del job no se suma a la espera de 10 segundos. Por eso mismo, si una ejecución tarda más de 10 segundos, dos copias se ejecutan al mismo tiempo: flock lo evita.

Con un timer de systemd

Un timer de systemd acepta segundos, y se comporta distinto del loop: una hora que llega mientras el servicio sigue activo no inicia otra copia. Elige el que corresponda a tu job: con el loop, las ejecuciones pueden superponerse; con el timer, una ejecución lenta retrasa la siguiente. Dos archivos, /etc/systemd/system/job.service:

[Unit]
Description=Job every 10 seconds

[Service]
Type=oneshot
ExecStart=/ruta/al/job.sh

Y /etc/systemd/system/job.timer:

[Unit]
Description=Run job.service every 10 seconds

[Timer]
OnCalendar=*:*:0/10
AccuracySec=1s

[Install]
WantedBy=timers.target

Después:

sudo systemctl daemon-reload
sudo systemctl enable --now job.timer
systemctl list-timers job.timer

• AccuracySec=1s es importante. Por defecto, un timer puede dispararse hasta un minuto después de su hora, para agrupar las activaciones: para un job cada 10 segundos, eso no sirve.
• systemd-analyze calendar "*:*:0/10" muestra las próximas horas, para comprobar la expresión.
• La salida va al journal: journalctl -u job.service.

Cuándo es mejor no programarlo

Un job que tiene que ejecutarse cada uno o dos segundos suele funcionar mejor como un proceso que queda en ejecución, con un loop y su propia pausa, supervisado por systemd. Iniciar un proceso nuevo cada pocos segundos también tiene un costo: el intérprete, las conexiones, la configuración.

Si vienes de Spring o Quartz, una expresión con segundos, como */10 * * * * *, no tiene equivalente en crontab: el probador de cron te dice cuáles sí.

Vigílalo por minuto

CronDrive revisa el horario por minuto. Puedes monitorear la ejecución de cada minuto, con las llamadas en la primera de las dos líneas, pero eso no comprueba la ejecución intermedia. Si necesitas detectar cada fallo o cada ejecución ausente, este seguimiento por minuto no es suficiente.