Score:0

How to troubleshoot Ubuntu Certbot cron/timer?

us flag
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:        20.04
Codename:       focal

and have installed certbot via apt-get

My issue is that it is the second time that certificates expire and the cron(also systemd service) installed by certbot is not working.

I see this file created:

/lib/systemd/system/certbot.timer

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/certbot.service

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

/etc/cron.d/certbot

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
#
# Important Note!  This cronjob will NOT be executed if you are
# running systemd as your init system.  If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob.  For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

My init system is systemctl:

[[ `systemctl` =~ -\.mount ]] && echo yes || echo no
yes

I see there timer registered:

 systemctl list-timers | grep 'cert'
Fri 2022-03-25 17:36:31 UTC 6h left        Fri 2022-03-25 02:41:57 UTC 8h ago       certbot.timer                certbot.service   

I also tried to check timer calls to see if certbot timer was called at midnight one day before:

journalctl  --since "2 days ago" -u motd-news.timer 
-- Logs begin at Sun 2021-09-26 19:26:36 UTC, end at Fri 2022-03-25 11:37:03 UTC. --
Mar 25 09:54:16 ip-10-40-2-7 systemd[1]: motd-news.timer: Succeeded.
Mar 25 09:54:16 ip-10-40-2-7 systemd[1]: Stopped Message of the Day.
-- Reboot --
Mar 25 09:54:55 ip-10-40-2-7 systemd[1]: Started Message of the Day.
-- Reboot --
Mar 25 09:59:11 ip-10-40-2-7 systemd[1]: Started Message of the Day.
Mar 25 10:06:38 ip-10-40-2-7 systemd[1]: motd-news.timer: Succeeded.
Mar 25 10:06:38 ip-10-40-2-7 systemd[1]: Stopped Message of the Day.
-- Reboot --
Mar 25 10:08:45 ip-10-40-2-7 systemd[1]: Started Message of the Day.

I don't understand why certbot renew command this cron/timer is never called or is called and something fails (for this I need information where to check the logs).

Score:0
ru flag

This works for me

Your system doesn't use the cron so ignore that, it is systemd.

certbot.timer:

[Unit]
Description=Timer for Certbot Renewal

[Timer]
OnBootSec=300
OnUnitActiveSec=1d

[Install]
WantedBy=timers.target

certbot.service:

[Unit]
Description=Let's Encrypt renewal
Wants=network.target
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet --agree-tos
ExecStartPost=/bin/systemctl reload nginx.service
ExecStartPost=/bin/systemctl reload postfix.service
ExecStartPost=/bin/systemctl reload dovecot.service

I also see you rebooted your computer a couple of times, but you are also looking at motd-news.timer. So you won't see anything about certbot's timer!

us flag
Thanks @Alex so wha should I be looking at in the command journalctl to see only certbot
ru flag
`sudo journalctl -u certbot`
us flag
Thanks so it seems like it runned but failed `Mar 24 11:29:35 ip-10-40-2-7 certbot[1842612]: All renewal attempts failed. The following certs could not be renewed: ` I cannot see anymore information why it failed
ru flag
Try `sudo certbot renew` and see what the error message is.
ru flag
Also there is a logfile in `/var/log/letsencrypt/` on most systems.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.