PHP-FPM – Slow Log ERROR: Failed to ptrace(ATTACH) Child: Operation Not Permitted

centoscentos7PHPphp-fpm

I am running CentOS 7 with Nginx/PHP-FPM. To debug a couple of slow WordPress and CodeIgniter requests I activated PHP-FPMs slow log feature in www-pool.conf:

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 4s

The slow requests are getting logged but the meaningful stack trace are not printed to www-slow.log. The file is being generated but empty and the default error.log is showing entries like this:

[12-Nov-2017 16:50:26] WARNING: [pool www] child 21497, script '/usr/share/nginx/www/wordpress/index.php' (request: "GET /index.php") executing too slow (4.161874 sec), logging
[12-Nov-2017 16:50:26] ERROR: failed to ptrace(ATTACH) child 21491: Operation not permitted (1)
[12-Nov-2017 16:50:26] WARNING: [pool www] child 21491, script '/usr/share/nginx/www/wordpress/index.php' (request: "GET /index.php") executing too slow (4.590854 sec), logging
[12-Nov-2017 16:50:26] ERROR: failed to ptrace(ATTACH) child 21490: Operation not permitted (1)
[12-Nov-2017 16:50:26] WARNING: [pool www] child 21490, script '/usr/share/nginx/www/wordpress/index.php' (request: "GET /index.php") executing too slow (4.620915 sec), logging
[12-Nov-2017 18:03:52] ERROR: failed to ptrace(ATTACH) child 21523: Operation not permitted (1)
[12-Nov-2017 18:03:52] WARNING: [pool www] child 21523, script '/usr/share/nginx/www/wordpress/wp-admin/index.php' (request: "GET /wp-admin/index.php") executing too slow (4.366918 sec), logging

The log files/folder are owned by php-fpm user under which php-fpm is running.

Any ideas?

Best Answer

This is being caused by SELinux, which blocks the web server (and PHP, which runs under the web server's context) from attaching to processes to trace their execution.

This was reported to Red Hat some time ago, but they declined to do anything about it.

You can check your /var/log/audit/audit.log and you'll find this denial logged in an AVC similar to:

type=AVC msg=audit(05/21/2015 21:37:21.028:14259) : avc: denied { sys_ptrace } for pid=1385 comm=php-fpm capability=sys_ptrace scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability

To resolve the problem for your own server, you can create a local SELinux policy module with audit2allow. Feed the AVC to audit2allow by standard input, something like this:

$ audit2allow -M php_ptrace

type=AVC msg=audit(05/21/2015 21:37:21.028:14259) : avc: denied { sys_ptrace } for pid=1385 comm=php-fpm capability=sys_ptrace scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=capability

You run the command and then paste in the AVC log entry into the terminal and press Ctrl-D. You'll get a generated policy and instructions:

******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i php_ptrace.pp

So, run that command, and you're done.

Related Solutions

PHP-FPM seg faults, how to find out why

You could try to find the line of code where php quits using XDebug.

Nginx – php-fpm, nginx magento store. Coming to a halt

SIGBUS
The SIGBUS signal is sent to a process when it causes a bus error. The conditions that lead to the signal being raised are, for example, incorrect memory access alignment or non-existent physical address.

So it sounds like you are over committing on memory and PHP is falling down because of it.

You could confirm by looking at the last kernel messages

dmesg

Or by simply checking your committed memory - and comparing to how much memory you actually have available.

cat /proc/meminfo | grep Committed_AS

Your issue sounds like it stems from a memory leak in a PHP extension - or simply bad Magento programming - the latter is more likely.

Thankfully, the former is easy to test. Just disable all PHP extensions apart from the bare minimum required for Magento (eg. APC/Source Guardian/Ioncube etc.).

The latter can be tested by merely following a standard Magento debug process.

At present, you are merely masking the problem by lowering the max requests value. If you don't have a good level of experience with Nginx and PHP-FPM - don't bother drinking the Magento kool-aid that Nginx/PHP-FPM is the holy grail of performance. It isn't. And its clearly causing you problems. My suggestion would be to go back to a more manageable Apache/mod_php configuration, which will yield the same performance and be more stable.

Best Answer

Related Solutions

PHP-FPM seg faults, how to find out why

Nginx – php-fpm, nginx magento store. Coming to a halt

Related Topic