Olhando /etc/cron.d/certbot, acho que não! Esse arquivo inclui a linha:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew
e, a menos que eu esteja lendo errado, a renovação só acontecerá se houver um arquivo executável e legível chamado /usr/bin/certbot(existe) E se houvernãoum diretório chamado /run/systemd/system(mas existe, mesmo que esteja vazio).
Então, estou certo e a certbot -q renewparte nunca funcionará? Existe talvez algum outro lugar que também desencadeie a renovação? (Achei que poderia haver algo /run/systemd/systemporque está sendo verificado, mas como eu disse, não há. Por curiosidade, por quefazeste pequeno script verifica a inexistência de /run/systemd/system?)
Este está executando o mais recente certbot(v1.18.0, instalado ontem usandoas instruções oficiais) no Ubuntu 18.04.
A propósito, eu corri:
test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot renew --dry-run
como root na linha de comando e sai imediatamente com um status de saída 1.
Responder1
Se o sistema estiver usando systemd, ele será executado como um serviço systemd, acionado por tempo.
Se você executar, systemctl status certbot.timerobterá o status do serviço que é acionado certbotno systemd.
É por isso que o script cron está configurado para não executar a renovação se o systemd for detectado na máquina.