Lately, I've been doing a lot of changes on my website like adding and editing existing website config in ISPConfig. Specially when using resync under Tools. Plus running ispconfig_update.sh --force. Whenever I do the above stuff, nginx and php are the most affected services. Even if I just edit one line in nginx Directives, all websites are being affected by the restart of nginx and php-fpm. Worse is when running resync under tools, it took several restart on nginx and php-fpm before it finishes its task. It there any other way to avoid repetitive restart on this services?
ISPConfig reloads the service if possible. A restart is only made when required to apply specific changes, especially when related to SSL. If you disable config check under system > server config > web, then restarts are delayed and only one restart is made for all changes, but this also means that failures in website config can not be detected reliably anymore and rolled back, so if there is a failure, your whole system will be down with all sites without automatic failure recovery. That's a decision that you have to make. E.g. when you do a resync for whatever reason, then it can make sense to deactivate config check before you do that and in case of a failure, you must find and resolve it manually then.
Did you mean the "Test webserver configuration on restart"? If I uncheck that, and make some changes, how many minutes will ISPConfig wait and reload/restart the services?
yes. ISPConfig server.sh runs once a minute and will process during that time all pending requests and the restart will be done when these pending requests are finished.
I had to update a bunch of domains with the same thing, (adding an ipv6 address), so I disabled the server.sh in crontab, did all my changes, and then re-enabled it in crontab Btw, you should change the graceful wait interval of apache so it doesn't wait a long time for child connections that have not yet closed their connections.. Here is an excerpt: When using graceful restart, the parent apache process stops accepting new connections and waits forever for all the child processes to exit. So essentially the web server is dead (other than existing connections) until all the existing children exit. In the normal use case of short-lived http/https connections, this is not a problem when doing a graceful shutdown or restart...it should normally take a second. The problem is when you have something that delays the children exiting, such as persistent websocket connections. In that case the server will never actually manage to gracefully stop/restart...it will just sit there forever in a semi-dead state. You can adjust the delay using the GracefulShutdownTimeout directive: https://httpd.apache.org/docs/2.4/mod/mpm_common.html#gracefulshutdowntimeout By default it is set to 0 (infinite). 5 seconds is a more reasonable value. Note that when using systemctl to restart the server, it will only wait a maximum of 90 seconds by default before forcing it to kill the child processes (rather than forever), which is why you are seeing this 90 second delay. This is set in /etc/systemd/system.conf.