Hello community,
I’m experiencing an issue with Hestia. After editing the configuration of a web domain, Hestia is not automatically restarting the PHP-FPM and Nginx services as it used to.
I’ve verified that manually restarting the services works correctly.
Any clues on how to solve this? I tried to find the file responsible for this function to see if it can be corrected, but I couldn’t locate it.
Any help or guidance would be greatly appreciated. Thank you!
Thank you for your interest and your response.
For example: If I modify the PHP version, change from PHP 7.4 to 8.2, save and enter the domain, I get an error, then I check the nginx and it has not been restarted, or the php, and neither, I restart them and immediately apply the change. Before I didn’t have to do all that, the reboot applied itself.
I verified the file and it is unchanged, it is original with the same hestia installation date. How do you think I could debug the error?
More detail:
The problem started when I updated everything from Ubuntu 22.04, including PHP, nginx, etc… I was following a guide to install Collabora.
What error?
The first you should do is check the logs in /var/log/hestia/ so edit the domain again and after that check the system log /var/log/hestia/system.log
Important: I have accessed via SSH and used v-restart-service nginx, nothing happened in the console, it just accepted the command, but the restart was not applied, I checked it in hestia.
I was wrong, no visible error appears.
I did exactly what you told me, see what logs are generated when I change the PHP version of a domain and apparently it looks fine there.
But if I move to the administrative area where I have NGINX, and it shows me the minutes that have passed since the last manual restart, that is, it has not been restarted.
When checking infophp() on the same domain I get an error, I just restart nginx manually if it accepts the change.
LOG - system.log
2024-04-11 16:14:42 v-restart-service 'nginx' ''
2024-04-11 16:14:42 v-restart-service 'php8.2-fpm' ''
2024-04-11 16:14:43 v-change-web-domain-backend-tpl 'admin' 'domain.com' 'PHP-8_2'
2024-04-11 16:14:43 v-delete-fastcgi-cache 'admin' 'domain.com'
2024-04-11 16:14:44 v-restart-service 'nginx' ''
2024-04-11 16:14:44 v-add-web-domain-ssl-force 'admin' 'domain.com'
2024-04-11 16:14:45 v-restart-service 'nginx' ''
2024-04-11 16:14:45 v-add-web-domain-ssl-hsts 'admin' 'domain.com'
2024-04-11 16:14:45 v-restart-service 'nginx' ''
Well, keep in mind that v-restart-service 'nginx' '' is not restarting nginx but reloading it and that’s the reason the service in Hestia keeps showing the same uptime.
This is the command issued by the script:
systemctl reload-or-restart nginx
If you want to see whether it is working, check the nginx status and see the date and time for the last update:
systemctl status nginx --no-pager -l | tail -n1
I don’t know whether the changes you are performing must restart nginx instead of reload it…
Thank you very much for your response, it has been helpful for debugging.
I carried out the same procedure of changing the PHP version, and I verified with
systemctl status nginx --no-pager -l | tail -n1
and
systemctl status php7.4-fpm --no-pager -l | tail -n1
and both coincided that the reload had been done.
The problem persists; the page was not visible until I manually restarted Nginx, so we can deduce that the issue could be with Nginx. However, I’m running out of ideas on how to debug it.
Can you think of any way I could debug this?
Could you share that guide so I can know what you did?
This is the guide I followed:
But that guide uses Apache2 and maybe I’m wrong but seems you were using Nginx standalone, right?
In my default installation I did not install apache2, correct. When I used the first code in the guide, I ended up installing apache2 and then had to uninstall it manually.
I’m afraid I can’t reproduce the issue so I can’t help here 
I appreciate all your support, really.
What do you think is the best way to move to a new instance with Hestia freshly installed?
Above all, being able to migrate all Hestia users.
Just install Hestia in that new server with all the services you need and once configured, backup your users in the old server and restore them in the new server… but don’t do that all at once, first do several test to know that your users are being restored as expected.