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.
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
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.
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.
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.