Smart request handling bugfix
In this release we have made a small change to our PHP configuration to fix a problem with the smart request handling and the livefpm command on Hypernode. We discovered that since the latest PHP update it was not possible anymore to view the connection status of FPM requests as the app user for all PHP versions except for 5.5.
Instead of showing a connection state like BUSY, IDLE or GONE it would show a dash.
New behavior:
app@5vi8w1-testalex-magweb-do:~$ hypernode-fpm-status
20716 - 1.0s NL 1.2.3.4 GET testalex.hypernode.io/ (curl/7.47.0)
Expected behavior
app@5vi8w1-testalex-magweb-do:~$ hypernode-fpm-status
20716 BUSY 1.0s NL 1.2.3.4 GET testalex.hypernode.io/ (curl/7.47.0)Because of the same issue the smart request handling could not properly identify requests anymore where the visitor had already clicked away. Normally when a server is under a lot of stress a process which we call the goneslayer will start prioritizing still active connections over clients that have already given up.
This regression was caused by this change in PHP which resulted in process.dumpable now needing to be set to allow unprivileged users to list the connection information for the PHP-FPM child processes. This was a side-effect of the mitigation for CVE-2018-10545 which fixed bypassing OPcache access controls. But because Hypernode is not shared hosting we can safely re-enable this feature.
To prevent this from becoming a problem again in the future we have added extra integration tests for the expected behavior. This change will be deployed to all Hypernodes in the coming week. To check if the new configuration has already been propagated to your node you can run this ss command.
# Old configuration
$ ss -lp | grep 9000
tcp LISTEN 0 128 127.0.0.1:9000 *:*
# New configuration
$ ss -lp | grep 9000
tcp LISTEN 0 128 127.0.0.1:9000 *:*
users:(("php-fpm5.6",pid=27167,fd=0),("php-fpm5.6",pid=19184,fd=0),("php-fpm5.6",pid=19183,fd=0))
Alternatively you could try listing the associated file descriptors of an FPM child process
# Old configuration
$ ps ax | grep "pool [w]ww" | awk '{print$1}' | head -n 1 | xargs -I {} ls /proc/{}/fd
ls: cannot open directory '/proc/24804/fd': Permission denied
# New configuration
$ ps ax | grep "pool [w]ww" | awk '{print$1}' | head -n 1 | xargs -I {} ls /proc/{}/fd
0 1 2 3 4
Expanded list of automatically blocked bots
When a Hypernode becomes unresponsive our automation will inspect the running requests in order to try to detect known patterns of abuse. This is used for blocking brute-force attacks and for banning malicious or unwanted bots from your server to free up computational capacity for real visitors.
While it would be better for performance to preventively block those bots, our automation will try to do it for you as an attempt to save the shop from becoming overloaded. If a Hypernode is about to reach its limits and known bot patterns are detected in currently running requests our automation will use the nginx config reloader to detect if a new webserver rule will clash with any existing configuration, and if not, deploy a configuration file in the user NGINX directory.
When that happens, the user will receive the following type of email:
Today we have expanded this detection mechanism to detect and block some more known bad bots.