Hello all,
My hestia has been running without any problem for many months. But since the update to 1.6.0, I noticed that every morning at 7:45 am the services restart automatically. (I don’t know if it was the case before).
And I receive daily at the same time an email “Apache restart failed” containing only the text “Syntax OK”.
Everything works normally and apache seems to be started correctly. I tried to restart it by hand, everything is fine and I don’t receive this email.
If you have any idea what the problem is that is causing me to get this alert message. Thank you.
Good luck all.
We are aware of the bug
Can you please check the time that v-update-letsencrypt-ssl cronjob runs?
oops… how to see this ?
But I have this in the apache error log
[Wed Jun 22 07:45:03.839808 2022] [mpm_event:notice] [pid 4087614:tid 140113139539264] AH00492: caught SIGWINCH, shutting down gracefully
[Wed Jun 22 07:45:04.363768 2022] [ssl:warn] [pid 25873:tid 140252968996160] AH01909: 146.59.XXX.XXX:443:0 server certificate does NOT include an ID which matches the server n>[Wed Jun 22 07:45:04.364054 2022] [suexec:notice] [pid 25873:tid 140252968996160] AH01232: suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Wed Jun 22 07:45:04.396717 2022] [ssl:warn] [pid 25891:tid 140252968996160] AH01909: 146.59.XXX.XXX:443:0 server certificate does NOT include an ID which matches the server n>[Wed Jun 22 07:45:04.399088 2022] [mpm_event:notice] [pid 25891:tid 140252968996160] AH00489: Apache/2.4.53 (Ubuntu) mod_fcgid/2.3.9 OpenSSL/1.1.1f configured – resuming norm>[Wed Jun 22 07:45:04.399112 2022] [core:notice] [pid 25891:tid 140252968996160] AH00094: Command line: ‘/usr/sbin/apache2’
In “Crontab” tab in the admin user there is a line:
xx x * * * sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl
Check if it is close to the time you received the email.
Yeap! It’s very close (email received = 1min after cron) to the time when this cron starts: sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl Apparently I have the same issue and I’m glad it’s an already known bug 
Hello,
I ran: /usr/local/hestia/bin/v-update-letsencrypt-ssl the script lasts about 10 seconds and I didn’t receive any email.
However, my server has been very busy for a few days… And I discovered that it was the Windows Azure CDN installation that was overloading one of my sites with requests coming from Azure. (probably a poorly designed control probe at microsoft). I removed the CDN and my server breathes better. This should facilitate the execution of the CRON and avoid the error mail.
Thank you all for your help.
No other users have reported similar issues. And 10 seconds with a lot of domains or an ssl update is reasonable.
Uh… I’m just pointing out that I don’t seem to have this problem anymore. That the problem was indeed due to a slow CRON (letsencrypt) but because of my server which was slowed down by thousands of requests coming from the Microsoft CDN.
It happened today on one of my HestiaCP for the first time…
No error mail this morning for me, since my server is back to normal load. There is clearly a relationship between the execution of this cron and the server load. Basically if we receive this mail it’s because our server is a bit too busy and the CRON is running too long.
After reading the replies, I can presume that this is related to the renewal of the SSL certificates, but in my case I received seven errors but I have a total of eight certificates.
Nontheless it generated the LE certificates correctly, so I bet this error won’t show tomorrow or for the next months.
Got a similar error.
Subject: xxxxxx .com: apache2 restart failed
Body: AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using xxxxxx .com. Set the ‘ServerName’ directive globally to suppress this message
Syntax OK
(xxxxxx .com was my actual domain name).
The mail came within less than a minute after sudo /usr/local/hestia/bin/v-update-letsencrypt-ssl had run.
The server (VPS 2GB RAM) gets a tiny amount of traffic, especially at 1AM.
I am also seeing this email daily. It’s because Hestia is running a config check on Apache and misinterpreting the result.
Hi Eris, I am also getting same mail on some servers which have a larger (around 40 sites) . This is indeed the same time (1 minutes later) after Letsencrypt cronjob is run.
My servers have 8 cores / 64GB ram with just 10% usage at the cronjob run time.
i also have the same issue…
We have added an debug method to it:
Please enable “DEBUG_MODE” in /usr/local/hestia/conf/hestia.conf by changing it to yes wait for the cronjob and check /var/log/hestia/debug.log after you have received the email
Any information why is helpfull 
I only received it in one day (see above), as I expected, I am almost sure it is related to the let’s encrypt renewal.
Same bug here. I got one mail with the apache2 restart failed and another mail with the letsencrypr cronjob title and this content:
PHP Warning: PHP Startup: Unable to load dynamic library ‘php_mysql.dll’ (tried: /usr/lib/php/20200930/php_mysql.dll (/usr/lib/php/20200930/php_mysql.dll: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/php_mysql.dll.so (/usr/lib/php/20200930/php_mysql.dll.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library ‘php_gd2.dll’ (tried: /usr/lib/php/20200930/php_gd2.dll (/usr/lib/php/20200930/php_gd2.dll: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/php_gd2.dll.so (/usr/lib/php/20200930/php_gd2.dll.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
I am using gd2 mysql etc php extensions, however I have no idea why there’s a reference to a 20200930 folder as the server was setup one month ago. However, I bought the domain around that time and registered it for the first time with let’s encrypt.
I think it is for php8.0 release check if the both existing.
/usr/lib/php/20200930/php_gd2.dll
Try reinstalling the packages php-mysql and php-gd2
I didn’t get this error message again, so ignoring it