0

I've Debian Stretch running nginx + php7 for a wordpress website.

This question is not about wordpress, but about php7.0-fpm (it's just that wordpress is showing my current php problem). And please, don't tell me to "google it", I dit for half a day, tried all the possible solutions. None worked.

In a Wordpress post, when I upload a file I get an HTTP error (note that this doesn't happend on plugin updates and similar operations).

There are the file types I tried from which I get an error :

jpg png pdf mp3

And there are the file types I tried from which I don't get an error :

txt doc docx

This is the php7.0-fpm.log when I restart php7.0-fpm and try to upload three different files :

[11-Aug-2017 14:44:32] NOTICE: fpm is running, pid 661
[11-Aug-2017 14:44:32] NOTICE: ready to handle connections
[11-Aug-2017 14:44:32] NOTICE: systemd monitor interval set to 10000ms
[11-Aug-2017 14:50:35] WARNING: [pool www] child 749 exited on signal 6 (SIGABRT) after 363.688500 seconds from start
[11-Aug-2017 14:50:35] NOTICE: [pool www] child 1234 started
[11-Aug-2017 15:03:06] WARNING: [pool www] child 1546 exited on signal 6 (SIGABRT) after 183.839880 seconds from start
[11-Aug-2017 15:03:06] NOTICE: [pool www] child 1573 started
[11-Aug-2017 15:03:16] WARNING: [pool www] child 1573 exited on signal 6 (SIGABRT) after 9.961325 seconds from start
[11-Aug-2017 15:03:16] NOTICE: [pool www] child 1574 started

This is nginx' error.log :

2017/08/11 14:50:35 [error] 776#776: *76 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 123.123.123.123, server: www.website.com, request: "POST /wp-admin/async-upload.php                       HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "www.website.com", referrer: "https://www.website.com/wp-admin/post.php?post=1055&action=edit"
2017/08/11 15:03:06 [error] 778#778: *284 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 123.123.123.123, server: www.website.com, request: "POST /wp-admin/async-upload.php                       HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "www.website.com", referrer: "https://www.website.com/wp-admin/post.php?post=1055&action=edit"
2017/08/11 15:03:16 [error] 778#778: *295 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 123.123.123.123, server: www.website.com, request: "POST /wp-admin/async-upload.php                       HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "www.website.com", referrer: "https://www.website.com/wp-admin/post.php?post=1055&action=edit"

This is the interesting part (I presume) of my nginx website block :

location ~ \.php$ {
            try_files $uri =404;
            include fastcgi_params;
            fastcgi_read_timeout 150;
            fastcgi_pass unix:/run/php/php7.0-fpm.sock;
            fastcgi_split_path_info ^(.+\.php)(.*)$;
            fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

This is the interesting part (I presume) of my php7.0 www.conf :

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Questions are :

  • Why does childs exits ?
  • If this is due to a misconfiguration, how can I resolve the problem ?

If you need more informations on my setup, feel free to ask for.

Thanks !

bmourey
  • 1
  • 1
  • What is the hardware environment for the service? Your PHP-pool worker limits are quite low for a site that has any traffic at all. That doesn't cause these errors though. Are you using the latest packages for PHP and latest updates for WordPress? What kind of media plug-ins you have in WordPress that could process those files? – Tero Kilkanen Aug 11 '17 at 17:35
  • That's a huge read timeout. Do you really want your precious threads being hogged by a single request that long? Also, can you send the output of phpinfo? This is probably a bug or incompatibility in PHP itself; SIGABRT shouldn't happen in response to errors within scripts. – Zenexer Aug 12 '17 at 09:36
  • @TeroKilkanen VPS, 3 cores, 1GB ram, that looked good to me as the website was on a 2 cores 1.5GB ram before. But maybe it isn't! Server and website are fully up to date yes. I don't have any media plugin apart from ewww image optimizer but it's run once per hour with CRON so it shouldn't interfere. And it doesn't : problems the same with barely no plugin active (just woocommerce). I will try disabling every plugins including woocommerce as soon as I can and tell you about it. – bmourey Aug 13 '17 at 07:08
  • Actually it might be your resource limits in PHP-FPM. Try raising `max_children` to 100, `start_servers` to 10 and `min_spare_servers` to 5, `max_spare_servers` to 10. – Tero Kilkanen Aug 13 '17 at 10:10
  • @Zenexer phpinfo looks like a good path to go,. When I try tro process it the original way (make file then load it in browser) I get a 502 error (cloudflare). I did it from bash and this is the output : [link](https://pastebin.com/BjcA93Tu). Looks like there is a problem with imagick. I'm going to remove then install again imagick. By the way, if the problem is there, it means this little php snippet we see everywhere to for wp to use gd instead of imagick ([link](https://stackoverflow.com/questions/23343691/http-error-when-uploading-an-image-via-the-wordpress-media-uploader)) doesn't work. – bmourey Aug 14 '17 at 06:57
  • @Zenexer still get `*** Error in `php': corrupted size vs. prev_size: 0x0000563979113de0 ***` about imagick. Maybe that's a bug, should I report ? – bmourey Aug 14 '17 at 07:05
  • @TeroKilkanen I dit change the resources limits in php-fpm. It didn't change anything. For my own conciousness I tried again the functions.php snippet I was refering to in Zenexer answer, and now, I don't know why, this solution works. This means here **on debian stretch** there is a bug with imagick + php7 (it worked like a charm on jessy). I'll do my researches to debug imagick though. – bmourey Aug 14 '17 at 07:18
  • 1
    @Tero Kilkanen I don't want to be mean, but I cannot emphasize enough how bad that advice is, especially for a small server. That just masks the real problem; if that solves your issue, you have runaway requests that are taking way too long. – Zenexer Aug 14 '17 at 08:11
  • 1
    As awesome as ImageMagick is, it's become apparent recently that it's not a good choice for use on websites. I recommend disabling it and switching to gd as a security measures. There are workarounds for the vulnerabilities, but you're better off reserving ImageMagick for the processing of clean data. – Zenexer Aug 14 '17 at 08:13
  • Thanks @Zenexer, I assumed that one way resource exhaustion could show itself is via that `SIGABRT` message. Since I didn't know all PHP modules that were in use, I didn't suspect that incorrect image processing integration would be the culprit. And yes, `gd` is the choice over here. You should post your comment as an answer. – Tero Kilkanen Aug 14 '17 at 08:41
  • You're the one who figured out it was ImageMagick. ;). You should post the command you used and mark that as the answer. – Zenexer Aug 14 '17 at 08:43
  • Yes, problem solved, thank you both ! Waiting for the answer to mark it correct. – bmourey Aug 14 '17 at 11:23

0 Answers0