Certbot automatic renew command

Help
1

Hello,

i have a question about the next command:

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

As far as i understand these are 3 commands, first one is testing if certbot exists and is executable and no system directory exist. If true (&& condition) then the second command is pause a random time before executing the renew command. There i get stuck, the result of this command will always be 0 i think so the renew command will not happen because of the && condition. At least thats what i think is happening on my system because the renew action will not happen. Do i understand it correct?
Running this command with systemd.timer and in a crontab job (as default installed by letsencrypt) on Google Cloud Platform Ubuntu 22.04.2 LTS. Sorry if I didn't describe everything clearly but I'm just an amateur.

2

That's good, right?

Exit codes work a little bit counterintuitive. An exit code of 0 means success and non-zero not successful. So an exit code of 0 means && would continue.

4 Likes
3

You can test that command in pieces at the command prompt.

On my Ubuntu that command doesn't work. But, because of the initial test

sudo test -x /usr/bin/certbot -a \! -d /run/systemd/system && echo Next
(produces no output)

perl -e 'sleep int(rand(10))' && echo DoRenew
Outputs:
DoRenew

Where did you get that command example? You might want to try the example from the docs instead
https://eff-certbot.readthedocs.io/en/stable/using.html#setting-up-automated-renewal

And, you would use either a cronjob or a systemd timer - not both.

4 Likes
4

I think this was recommended in the early Certbot documentations where one would manually add a cronjob. Although I'm not sure if perl was always used, currently some non-snap instructions use python to delay a random amount of time, e.g. Certbot Instructions | Certbot

4 Likes
5

Thanks.

I am not a bash test wizard. But I don't see any problem with the sleep part. I just wonder in what context that test works. If they copied the command from another O/S maybe it's not right for their system? I'm guessing. In any case, that command wouldn't run the renew on my Ubuntu. The -x part is fine but the -a component causes the issue.

3 Likes
6

Isn't that weird, as the -a option is just the test version of a boolean AND?

4 Likes
7

Yes, but, I have a /run/systemd/system folder

So, this:

sudo test \! -d /run/systemd/system && echo Next
sudo test ! -d /run/systemd/system && echo Next
sudo test -d /run/systemd/system && echo Next
Next
3 Likes
9

@markladage, what shows (on your system)?:
test -x /usr/bin/certbot && True1
test \! -d /run/systemd/system && True2
test -x /usr/bin/certbot -a \! -d /run/systemd/system && TrueBOTH

2 Likes
10

Makes sense, right? For me, it's just the opposite.

If you're running systemd, you'd have a systemd timer and wouldn't need a cronjob :wink:

Although that's just for systemd systems where the timer would automatically be installed and the instructions wouldn't know that for sure? Hmm.. Sure is a little bit fishy..

3 Likes
11

No, I get that a product may install both not knowing what kind of system is active and so disable the cron (w/the ! -d check) if the systemd timer is used.

And, maybe that's what Certbot did way back. But, for any one person they should know what they have and don't need a cronjob if they have a systemd timer.

The poster mentioned using both and is Ubuntu 22 so they shouldn't need the cronjob because they should have the timer. And, the failure of their very old syntax of cronjob isn't running because it's on systemd and not because of the random sleep they suspected of being a problem.

@markladage If you want to test your renew try this first:

sudo certbot renew --dry-run

(omit sudo if you don't need it)

If this works then there is something wrong with your systemd timer. Which you could replace with a cron but not that format you are using. Use the one I pointed to in the docs earlier.

4 Likes
12

If you just want to know if certbot is running [regardless of how it was called], then check the usage log file:
/var/log/letsencrypt/letsencrypt.log

2 Likes
13

Thank you all for the responses. I didn't know that the command installed on the GCP machine was an old command, I'll pay more attention next time. The solution suggested by @MikeMcQ in his post works for me.

https://eff-certbot.readthedocs.io/en/stable/using.html#setting-up-automated-renewal

Run the following line, which will add a cron job to /etc/crontab:

SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

Thanks everyone.

2 Likes
14

Yep thats true, got a little bit confused :rofl:

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.