No crontab entry, after (successful) installation

Having followed the Certbot Instructions in the (excellent) docs, I only have one question:
(my HTTP website is running nging with pip).

After the step No8 (Set up automatic renewal) I get no error, but I don't see any new entry in my crontab.
Is this normal?

As for now, everything is ok.
Also: sudo certbot renew --dry-run --force-renewal ends successfully

Thanks in advance

Please don't use this option, it's almost never useful or necessary. In the case of a --dry-run, it's not necessary at all. Please forget that option exists at all.

With regard to the cronjob: I don't know, the Certbot website has multiple instructions, depending on your specific situation. So you'd need to inform us how you installed Certbot. When using snap, it doesn't use a cronjob, but a systemd timer instead.

3 Likes

what about systemctl list-timers?

2 Likes

Do you mean this step 8?

echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

From: Certbot Instructions

Because that is a routine Linux command which should create a file. Did you enter it just as described?

3 Likes

Yes, exactly this step (echo ... /null).
I followed the instructions for nging and pip
Below are the timers and no (new) entry in my crontab. :frowning:

NEXT                        LEFT        LAST                        PASSED       UNIT                         ACTIVATES
Tue 2025-04-29 20:08:06 UTC 11h left    Mon 2025-04-28 20:08:06 UTC 12h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Tue 2025-04-29 22:26:44 UTC 13h left    Tue 2025-04-29 07:28:40 UTC 1h 4min ago  apt-daily.timer              apt-daily.service
Wed 2025-04-30 00:00:00 UTC 15h left    Tue 2025-04-29 00:00:01 UTC 8h ago       dpkg-db-backup.timer         dpkg-db-backup.service
Wed 2025-04-30 00:00:00 UTC 15h left    Tue 2025-04-29 00:00:01 UTC 8h ago       exim4-base.timer             exim4-base.service
Wed 2025-04-30 03:14:54 UTC 18h left    Tue 2025-04-29 01:48:08 UTC 6h ago       man-db.timer                 man-db.service
Wed 2025-04-30 06:26:30 UTC 21h left    Tue 2025-04-29 06:56:13 UTC 1h 36min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Sun 2025-05-04 03:10:50 UTC 4 days left Mon 2025-04-28 11:53:40 UTC 20h ago      e2scrub_all.timer            e2scrub_all.service
Mon 2025-05-05 01:34:28 UTC 5 days left Mon 2025-04-28 11:53:40 UTC 20h ago      fstrim.timer                 fstrim.service
-                           -           -                           -            logrotate.timer

9 timers listed.

Yes, I copied/pasted, as all previous ones.
My machine is a clean Debian 12.10

With the pip instructions, the crontab step is indeed manual (compared with the automatically installed systemd timer with snap).

Was the file /etc/crontab actually created when you ran the "Set up automatic renewal" step?

1 Like

Yes, I see a /etc/crontab file and the last line is the:

0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q

So, I assume that the answer to my question is:

Don't look only the user's crontab (crontab -l) but also the system wide /etc/crontab file

Thanks for your help :folded_hands:

1 Like

What command did you use to verify that?

What does this say

sudo crontab -l
2 Likes

You should also be able to look at the logs (I think in /var/log/letsencrypt) and confirm that it's actually running each day and confirming that there aren't any certificates that need renewal yet.

3 Likes