Mirando /etc/cron.d/certbot, ¡no creo que sea así! Ese archivo incluye la línea:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
y, a menos que lo esté leyendo mal, la renovación solo se realizará si hay un archivo ejecutable legible llamado /usr/bin/certbot(hay) Y si haynoun directorio llamado /run/systemd/system(pero lo hay, aunque esté vacío).
Entonces, ¿tengo razón y la certbot -q renewbroca nunca funcionará? ¿Hay quizás algún otro lugar que también desencadene la renovación? (Pensé que podría haber algo /run/systemd/systemporque se está verificando, pero como dije, no lo hay. Por curiosidad, ¿por qué?haceeste pequeño script comprueba la inexistencia de /run/systemd/system?)
Esto está ejecutando la última versión certbot(v1.18.0, instalada ayer usandolas instrucciones oficiales) en Ubuntu 18.04.
Por cierto, he corrido:
test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot renew --dry-run
como root en la línea de comando y sale inmediatamente con un estado de salida de 1.
Respuesta1
Si el sistema utiliza systemd, se ejecutará como un servicio systemd, activado por el tiempo.
Si ejecuta systemctl status certbot.timerobtendrá el estado del servicio que se activa certbotdesde systemd.
Es por eso que el script cron está configurado para no ejecutar la renovación si se detecta systemd en la máquina.