For everybody on the Community: please note that many third party (DNS) plugins still rely on zope and the corresponding deprecated classes such as certbot.interfaces.IAuthenticator.
These deprecated classes have been removed from Certbot in 2.0.x and thus third party plugins installed e.g. using pip will result in an error when the user has switched to Certbot 2.0.x in the future if the plugin has not been updated correspondingly.
Is there any chance for Certbot nginx plug-in to support systemd start after a failed reload?
A major version seems a good time to make such changes
If no changes could there be some additional messaging in the log or console to make clear the reload failed and the native command used to start nginx?
I reference this 1Y old thread but this recurs from time to time. The subtle "quirk" is also implicated in other cases where it is difficult to identify the cause of nginx state confusion.
As an aside, I wonder why Certbot even tries starting nginx after a failed reload. Couldn't it just issue a failure in such a case instead of trying to start nginx directly and causing problems on systemd systems?
Thank you for testing. We would love to see as many users testing it in the real world as possible.
I think I remember this issue from working on the nginx plugin. Repeatedly running the installer would result in one extra blank line being inserted in the server block due to a quirk in the parser. This issue is present in the stable version of Certbot as well. Filed an issue for it.
It's nearly 5 years since the original issue was filed and it looks like users are still hitting it, something should be done. Maybe some platform-specific overrides to try systemd first, in environments where we'd believe it to be a safe default. It is a risky change though and I'm not sure there will be enough time before the stable release of 2.0 to develop, announce and test this. I will bring it up.
Well, right now Certbot nginx plug-in has an inconsistent pre-req for the state of nginx which is not documented and is not stable.
On non-systemd, Certbot does not require nginx to be started prior to running Certbot. The plug-in starts nginx properly if it wasn't running.
On systemd, Certbot requires nginx to be running. Otherwise the plug-in starts it incorrectly causing system instability.
It may be a failure of my imagination but are people really relying on the plug-in starting a non-running nginx on a non-systemd system?
If certbot 2.0 plug-in just started requiring nginx to be running the "start" code after a reload failure could just be removed. This would be a breaking change on non-systemd units for anyone who relied on the auto-start. Their remedy is just to start nginx before starting certbot. It's not unusual to doc breaking changes on major releases. This seems clear enough to describe.