My web server is (include version):
Manual renewal using DNS challenges. Using this automatic renewal method (for GoDaddy)
The operating system my web server runs on is (include version):
I can login to a root shell on my machine (yes or no, or I don't know):
I have certbot installed via snap on my Ubuntu server. I know snap auto-generates the timers, and has them run. What I'm wondering is if I can specify the time that the timers are set to for renewal. The web-service takes about 20 minutes to fully initialize, so I'd like to have the renewal take place during off hours at a consistent time. Does anyone know how to modify the template that snap uses to generate these timers?
The Certbot snap should create just one single timer entry. You can find the file that defines it (or a symbolic link to that file) in
I think the default settings are
which basically means "run at a completely random time twice a day", if I remember correctly.
You could edit this file and change the
OnCalendar time to a region of the day you consider more appropriate (I'm not sure whether systemd makes this relative to UTC by default or to your local timezone if one is defined via
/etc/localtime!), and reduce
RandomizedDelaySec so the random delay is significantly smaller. (It's still polite to have some amount of randomness added to the start time to reduce the chance that you always start the renewal at the top of an hour or the top of a minute, since when lots of people do that, there are load spikes for the remote service at those times.)
What the timer is doing twice a day is starting the
certbot.service, which in turn is running the command
/usr/bin/certbot -q renew. This command tries to renew all certificates that are due (not just one particular certificate), which is defined within Certbot in a way having to do with the remaining time in the certificate's lifetime (by default, certificates that are expiring within 30 days from now).
The timer only calls
certbot which isn't required to restart a web server.
It can do so, but it is NOT required to do so.
You could also leave that timer alone and ensure the renewal process doesn't restart the web server.
It could send you an email instead...
Leaving that restart to be done by you on your desired schedule.
Thank you! This is exactly what I'm looking for. To clarify, after running the
/usr/bin/certbot -q renew command, if indeed there are certificates that need renewing, that is when the renewal will run, which in turn triggers the various hooks associated with renewal, otherwise nothing happens. Is that correct?
Yes, that's exactly right. If you run the
certbot renew command and it sees that nothing needs to be renewed on that occasion¹, then it will just give up, unless you also use
--force-renew (which is typically unnecessary or even counterproductive).
That makes it safe to run this command frequently in the sense that it will generally not do unnecessary work, although if you want control over (as you mentioned) the time of day when it can run in order to avoid random disruptions, you can definitely change the timer or cron job in order to constrain that.
¹ In addition to checking the certificates' expiration date, Certbot now also checks their revocation status using OCSP queries. This helps to promptly renew certificates that are not yet expired but that have been revoked for some reason.
To me, it depends on how many certificates are being handled by
If only one, then the restarts would only occur once every 60 days - negligible impact.
But as the certificate count increases, and the likelihood of them renewing at different intervals is high, the number of restarts within that 60 day window could increase proportionally.
Meaning that if you have a dozen certs, you might (on average) see your system restarting every 60/12 days.
Please know that systemd has an override system, there's no need to edit the unit files in
systemctl edit certbot.timer
will take you to an empty file where you can override whatever you want. Just check if you're adding or replacing the directives.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.