I ran this command: whenever systemd is running the default certbot.timer task, I get errors (below) and apache2 fails to come back up. sudo certbot renew --dry-run produces the same result - apache2 is dead after running it.
It produced this output: I can provide the entire output if necessary, but here is the output after the certbot.timer task tries to bring apache2 back up:
2020-05-26 21:51:04,811:INFO:certbot.hooks:Running post-hook command: apachectl -k start
2020-05-26 21:51:05,214:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/usr/bin/certbot", line 11, in <module>
load_entry_point('certbot==0.31.0', 'console_scripts', 'certbot')()
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1365, in main
return config.func(config, plugins)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1272, in renew
renewal.handle_renewal_request(config)
File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 477, in handle_renewal_request
len(renew_failures), len(parse_failures)))
certbot.errors.Error: 4 renew failure(s), 0 parse failure(s)
My web server is (include version)/The operating system my web server runs on is (include version): Apache/2.4.38 (Raspbian)
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0
port 80 namevhost home.baldockery.com /etc/apache2/sites-enabled/000-default.conf:27
port 443 namevhost home.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:179
port 80 namevhost openhab.baldockery.com /etc/apache2/sites-enabled/000-default.conf:36
port 443 namevhost openhab.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:50
port 80 namevhost nodered.baldockery.com /etc/apache2/sites-enabled/000-default.conf:45
port 443 namevhost nodered.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:66
port 80 namevhost dakboard.baldockery.com /etc/apache2/sites-enabled/000-default.conf:54
port 443 namevhost dakboard.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:89
port 80 namevhost mypi.baldockery.com /etc/apache2/sites-enabled/000-default.conf:63
port 443 namevhost mypi.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:113
Unmatched sections or containing irregularity:
port 80 namevhost baldockery.com /etc/apache2/sites-enabled/000-default.conf:1
port 443 namevhost baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:1
alias baldockery.com
port 80 namevhost enphase.baldockery.com /etc/apache2/sites-enabled/000-default.conf:72
port 443 namevhost emonpi.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:136
port 443 namevhost test.baldockery.com /etc/apache2/sites-enabled/default-ssl.conf:157
I corrected the redundant alias and the unmatched sections for the various virtual servers. And I updated the Route53 IP address for the ones that I had let get out-of-date. Now sudo certbot renew runs without errors. I restarted the timer. Hopefully when it next runs apache2 stays up.
After I corrected my configuration I ran certbot renew manually and it worked, so now when I try to test if certbot will stop and start apache2 successfully, it doesn't ever stop it because none of the certificates are up for renewal.
I have some time to look at this again today, and I'm wondering if you have suggestions on how to check if certbot still shows the problem.
My other question is if I should go back to using cron to periodically run certbot, and use post-hook "systemctl start apache", since systemctl is working for me and apachectl is not. Obviously it would be more satisfying to figure out what is going on with apachectl, but in the meantime is there any harm in going with this cron idea?
Before I updated Route53 with my current IP address for a few of those sites that I had let get out of date, every time the systemd certbot service ran it would try to renew the certificates for those sites, bring down apache and try to bring it back up. Two days ago, when I updated Route53 while working on this, I did a certbot renew and they successfully renewed. So now the certbot service doesn't find anything that needs renewing, so it never brings down apache. Thus the best simulation I know of now is to just try "apachectl -k start". When you asked if certbot still showed the problem, I wondered if you knew a way to make it do so.
standalone breaks the deploy hook logic.
As it requires you to stop the web service to spin up a new temporary web service.
You really should find a way to use the existing web server (and leave it running at all times).
Then you can use --deploy-hook