Facebook
Twitter
This is more or less a suggestion for a feature, but it's not really a feature in the classical sense to make it into the regular feature suggestion list, but a thing we'd need to overcome web server restart issues.
I recently suggested to lock the panel for additional configuration changes when one change is still processing. This was in regard of Let's Encrypt SSL certificate installations. Today I have seen the same issue in a different context: A customer has changed his webmail configuration. By that time, another webserver restart was going on, and for a short moment, the webmail configuration file was missing. This lead to one broken restart, and only for that we have monitoring scripts in place that auto-retry if an outage is detected, server was restarted later:
"httpd: Syntax error on line 353 of /etc/httpd/conf/httpd.conf: Syntax error on line 6 of /etc/httpd/conf.d/zz010_psa_httpd.conf: Could not open configuration file /etc/httpd/conf/plesk.conf.d/webmails/SUBSCRIPTIONDOMAIN.TLD_webmail.conf: No such file or directory"
This has lead to one failed restart. A second later, the file was there again, a new httpd restart attempt went through.
This is a general issue with configuration changes. It's been seen in the SSL context, and now in the web mail context. We've also seen it in our own scripts who by now check for other processes in the process list before they initialize a restart. Restart in this regard also meaning "reload" (same issue).
What we'd need for a perfectly failproof system are two things:
1) Locking the panel from configuration change execution while a httpd or nginx restart process is ongoing. Customer could still make changes, but these changes need to be queued and only executed through sw-engine after sw-engine is sure that no other changes are still pending and no httpd or nginx restart processes are currently pending. Very easy to program, simply look up the process list before running the configuraton update through sw-engine. If a restart is going on, wait a few seconds, test again, etc.
2) A method for non-Plesk tools to identify through a cli program whether Plesk is about to make a change through sw-engine or is currently doing so, so that non-Plesk scripts on the server can identify ongoing changes and prevent httpd restarts if Plesk is currently working on configuration changes.
By the large number of tests and similar cases we went through by now and the ever again returning issue with restart problems due to concurrent restarts of httpd I am pretty sure that these two measures would greatly increase stability of the system. As a matter of fact, almost all issues that we are seeing on our servers are linked to temporarily missing files as seen in the example above.
The suggestion described above may not be necessary on low volume systems, but on systems that host hundreds of domains of different users, these changes are vital.
I recently suggested to lock the panel for additional configuration changes when one change is still processing. This was in regard of Let's Encrypt SSL certificate installations. Today I have seen the same issue in a different context: A customer has changed his webmail configuration. By that time, another webserver restart was going on, and for a short moment, the webmail configuration file was missing. This lead to one broken restart, and only for that we have monitoring scripts in place that auto-retry if an outage is detected, server was restarted later:
Code:
Redirecting to /bin/systemctl status httpd.service
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/httpd.service.d
└─limit_nofile.conf
Active: failed (Result: exit-code) since Sat 2017-02-18 14:48:52 CET; 9s ago
Docs: man:httpd(8)
man:apachectl(8)
Process: 6538 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Process: 5417 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
Process: 6513 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 6513 (code=exited, status=1/FAILURE)
Feb 18 14:48:52 HOSTDOMAIN.TLD systemd[1]: Starting The Apache HTTP Server...
Feb 18 14:48:52 HOSTDOMAIN.TLD httpd[6513]: httpd: Syntax error on line 353 of /etc/httpd/conf/httpd.conf: Syntax error on line 6 of /etc/httpd/conf.d/zz010_psa_httpd.conf: Could not open configuration file /etc/httpd/conf/plesk.conf.d/webmails/SUBSCRIPTIONDOMAIN.TLD_webmail.conf: No such file or directory
Feb 18 14:48:52 HOSTDOMAIN.TLD systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Feb 18 14:48:52 HOSTDOMAIN.TLD kill[6538]: kill: cannot find process ""
Feb 18 14:48:52 HOSTDOMAIN.TLD systemd[1]: httpd.service: control process exited, code=exited status=1
Feb 18 14:48:53 HOSTDOMAIN.TLD systemd[1]: Failed to start The Apache HTTP Server.
Feb 18 14:48:53 HOSTDOMAIN.TLD systemd[1]: Unit httpd.service entered failed state.
Feb 18 14:48:53 HOSTDOMAIN.TLD systemd[1]: httpd.service failed."httpd: Syntax error on line 353 of /etc/httpd/conf/httpd.conf: Syntax error on line 6 of /etc/httpd/conf.d/zz010_psa_httpd.conf: Could not open configuration file /etc/httpd/conf/plesk.conf.d/webmails/SUBSCRIPTIONDOMAIN.TLD_webmail.conf: No such file or directory"
This has lead to one failed restart. A second later, the file was there again, a new httpd restart attempt went through.
This is a general issue with configuration changes. It's been seen in the SSL context, and now in the web mail context. We've also seen it in our own scripts who by now check for other processes in the process list before they initialize a restart. Restart in this regard also meaning "reload" (same issue).
What we'd need for a perfectly failproof system are two things:
1) Locking the panel from configuration change execution while a httpd or nginx restart process is ongoing. Customer could still make changes, but these changes need to be queued and only executed through sw-engine after sw-engine is sure that no other changes are still pending and no httpd or nginx restart processes are currently pending. Very easy to program, simply look up the process list before running the configuraton update through sw-engine. If a restart is going on, wait a few seconds, test again, etc.
2) A method for non-Plesk tools to identify through a cli program whether Plesk is about to make a change through sw-engine or is currently doing so, so that non-Plesk scripts on the server can identify ongoing changes and prevent httpd restarts if Plesk is currently working on configuration changes.
By the large number of tests and similar cases we went through by now and the ever again returning issue with restart problems due to concurrent restarts of httpd I am pretty sure that these two measures would greatly increase stability of the system. As a matter of fact, almost all issues that we are seeing on our servers are linked to temporarily missing files as seen in the example above.
The suggestion described above may not be necessary on low volume systems, but on systems that host hundreds of domains of different users, these changes are vital.