Ambas expresiones parecen un miércoles por la mañana, y solo una de ellas significa una vez. 0 10 * * 3 se dispara a las 10:00 del miércoles; * 10 * * 3 se dispara cada minuto de la hora de las diez, sesenta oportunidades de iniciar el mismo túnel. Si el comando es un lanzador que no comprueba si ya existe una sesión, la segunda versión no es un error de programación, es un bucle que produce propietarios en competencia. Lee el campo de los minutos antes de leer cualquier otra cosa.

Los cinco campos son minuto, hora, día del mes, mes y día de la semana, en ese orden, y un asterisco en el primero significa cada minuto.

El campo de los minutos decide cuántas veces

El número inicial es el minuto, así que 0 10 * * 3 es el primer minuto de la décima hora del miércoles. Sustituirlo por un asterisco conserva la hora y el día y elimina la propiedad de una sola vez, lo que produce sesenta coincidencias. Cron no elimina duplicados: cada coincidencia vuelve a lanzar el comando. Eso no es una sutileza sobre cron, es semántica de campos, y vale la pena leer la referencia del planificador instalado porque el orden de los campos y la columna opcional de nombre de usuario difieren entre el crontab de usuario y el del sistema.

Pruébalo con un comando inofensivo que registre su propia marca de tiempo durante un día. Una línea en el registro es una programación; sesenta líneas en una hora es una lección.

Qué hace un segundo lanzamiento al primero

Un lanzador bien educado nota que la conexión ya está activa y no hace nada. Una invocación directa de openvpn no: crea otro proceso, otro intento de enlazar un dispositivo o un puerto, y otro conjunto de rutas que compiten por los mismos destinos. En NetworkManager, las solicitudes de activación repetidas para una conexión suelen ser idempotentes, y es exactamente por eso que el problema queda oculto hasta que alguien usa un comando distinto. La programación debería preguntar al propietario que ya gestiona el túnel.

Después decide qué significa una solicitud mientras la conexión se está estableciendo. Ni la activación duplicada ni una cola de inicios pendientes son obviamente correctas; elige una y haz que el lanzador la implemente, en lugar de dejar que el planificador decida por accidente.

Cuenta los campos antes del comando

Los crontab de usuario y de sistema difieren en si aparece una columna de nombre de usuario antes del comando. Una entrada copiada entre ellos o se ejecuta con la cuenta equivocada o pasa el nombre de usuario como primera palabra del comando. Comprueba la referencia instalada en lugar de una guía, y cuenta los campos de tu propia línea. Una entrada de cinco campos con una sexta palabra antes del comando es un crontab de sistema; la misma línea en un crontab de usuario intenta ejecutar esa palabra como programa.

La identidad de ejecución lleva el entorno consigo. Un trabajo de cron no hereda un llavero desbloqueado, una petición interactiva de contraseña ni el directorio de trabajo en el que probaste.

Espera la disponibilidad, no el reloj

Un lanzamiento correcto no es un túnel que funciona. Es posible que el cliente aún esté resolviendo su punto final, autenticándose o instalando rutas cuando el trabajo termina. Cualquier tarea dependiente debería esperar el recurso protegido que realmente necesita, con un tiempo de espera acotado y un fallo registrado, en lugar de un número fijo de segundos. Esa distinción separa una programación que funciona casi siempre de otra que falla en silencio la mañana ajetreada.

Si en esa hora se requiere MFA interactiva, la tarea puede reclamar la atención de una persona pero no puede aportar la respuesta. Mantén ese caso explícito en lugar de incrustar una contraseña reutilizable o reintentar sin fin.

Para una activación genuinamente puntual, usa el mecanismo de un solo uso compatible. Una regla recurrente que hay que recordar y eliminar es un futuro lanzamiento duplicado.

Artículos relacionados