A .err file is created when Apache refused to strat with that config, so probably you still have your original error which prevents Apache from starting, just that ISPconfig was able to catch the issue this time and roll back the last working config. You can rename the .vhost file of the site to e.g. vhost.bak, then rename the vhost.err file to .vhost and restart Apache to see the error message during restart or in the log.
The error messages and the log files were not informative. Bad configuration is about all that they say. I restarted from the old configuration, re-did the Let's Encrypt generation, and it's now OK. Thx for your help. It remains a concern for me, though, that when a Let's Encrypt generation fails for whatever reason, ISPConfig creates an inconsistent Apache configuration rather that gracefully reporting the error. It's the second time for me - the first having forced me to destroy and re-create a website. Hopefully, there won't be a third, because my configuration is now complete, but I regard this behavior as a design issue
That's not the case. I don't know what you changed externally to make your config inconsistent, but it does not happen on any other system. In fact, if Let's Encrypt fails, ISPconfig gracefully reports this as a warning in the system log (see system monitor) and disables the Lets Encrypt checkbox also, to keep the UI in sync with your config. This does not affect Apache at all, so Apache will not be down, and a wrong system configuration will not get written.
Perhaps. But I did not do anything extenally to my configuration that could conflict with the apache config. The only external things I did were to 1/configure dovecot for UTF-8 and 2/add SNI entrie to postfix and dovecot. Period. I do not think that this could in any way disturb the SSL configuration (as I already said) and the problem, as I see it, happened completely unprovoked. Yes, the Let's Encrypt checkbox is disabled when it happens (without any warning being issued that I could see, though). But that' only true if the Apache configuration problem does not kill apache altogether, as it did in the first instance. Sorry, but I am fairly sure that "I ain't done nothing" that could explain why it happened
Just to mention that I add the same type of behivior after updating a manual SSl certificat to 1 of the web site, it completely broke down apache After a few trouble shooting did command : ipcs -s | wc -l result = 132 So did a clean up with this command for id in $(ipcs -s | awk '$3=="apache"{print $2}'); do ipcrm -s $id; done and then sucessfully restart Apache I was able to update my certificat no problem after As par ChatGPT i should add to /etc/httpd/conf.d/fcgid.conf FcgidMaxProcesses 100 FcgidMaxProcessesPerClass 20 to prevent futur growt of the Semaphore beyon reason that cause Apache to crash I was wondering if you have any comments about this thank you in advance