But why would you run the requests sequentially? Multiple terminal windows, multiple tmux sessions, or whatever; running the requests sequentially seems like a monumental time-waster.
@danb35 I am nearly certain that Certbot places a lock on /etc/letsencrypt to prevent multiple instances running.
@bilogic There are some tricks that may work. Some get messy.
But, those commands are a one-time thing. Once you've gotten the certs you use the certbot renew command which runs as a cron job or system timer. Why should it matter whether the renew takes the full 2 hours? In fact, if you stagger the initial requests by a day you would only renew one of them per day if that bothered you.
Among many reasons, the lock mentioned by @MikeMcQ is another.
Given the nature of the work (lots of idling time), it is much better for this script to be resume-able, it makes scripting easier and scalable (lighter memory footprint)
I actually have a PHP app that does this, but I'm tired of maintaining it and I like to leverage on the numerous DNS plugins available. (I'm tired mainly due to adding DNS support as I need wildcard certs)
My main use is for my sandbox/staging environment and things change/break often, so when all else fails, I need my recovery time to be short.
Well, the shortest you'll get is 30mins due to your DNS provider plus the lags between your attempts. Maybe just switch to a faster (free) DNS provider like Cloudflare.
Or, just preserve your prior certs and restore them directly when "things break" so you don't have to request fresh certs. You should be saving certs in durable storage anyway.
You might be able to kill a Certbot process, cleanup the lock, and return later. I don't recommend this. Would be fragile most likely. And, relies on specific CA auth-reuse periods.
You could also use the --config-dir option to keep the certs separate. But, using Certbot is then more difficult because you need to specify that each time for that cert. Even for renew
If you need more sophisticated control your best option is to use an ACME library and your own controller. But it sounds like you may already do that. Or, maybe try a different ACME client like lego. It might provide better concurrency options but I have never tried that so not sure. See: Installation :: Let’s Encrypt client and ACME library written in Go. Lego supports a very large number of DNS providers
I also use NameSilo, and it's really been no problem for me to set up multiple certs, all using the same hooks, which I have waiting for 60m (there were times for me when even 30m was just not enough! ). The overhead for a simple script sleeping for that long is trivial; I haven't looked into what certbot is chewing up itself as it waits. I would agree that a more "async" API would be cleaner, as would NameSilo actually supporting the process better, but the as-is functionality works well enough for me.
I have no idea what PHP is doing for you. My hooks are a couple small bash scripts written back in 2022 and have not had to modify them since (although I did tweak it to also update calendar entries for all my cert expiration dates back when LE stopped sending email notifications). As Mike said, you might have better luck with a client that has direct NameSilo support, but they're all going to be sitting and waiting for quite a while!
). The overhead for a simple script sleeping for that long is trivial; I haven't looked into what certbot is chewing up itself as it waits. I would agree that a more "async" API would be cleaner, as would NameSilo actually supporting the process better, but the as-is functionality works well enough for me.