HTTP 502 When Retrieving Attached Images

[sah62]

Every so often I see one of these errors in my web server log when a user is viewing a topic that includes image attachments:

Code Select Expand


X.X.X.X - - [23/Jan/2020:09:33:23 -0500] "GET /forum/index.php?action=dlattach;topic=27090.0;attach=19466;image HTTP/1.1" 502 182 "https://www.mysite.org/forum/index.php?topic=27090.msg182574;topicseen" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0"


It seems to happen more often when the topic includes multiple large attachments. In the case above, the topic had three images of sizes 3631.5 kB, 5732.19 kB, and 5918.2 kB, though of course the displayed thumbnails are much smaller. This looks like an "out of resources" issue, but I'm not sure which PHP configuration parameter I would need to adjust, or if it even make sense to try.

I've tried placing size limits on attachments. My user community is pretty clueless when it comes to re-sizing images manually, and I always end up with "I can't attach images" complaints when the limits are in place. Is there a way to get SMF to automatically re-size uploaded images?

[@rjen]

https://custom.simplemachines.org/mods/index.php?mod=4087

[sah62]

Image resizing hasn't eliminated the crash problem for me. I still see the occasional crash in my logs when processing image attachments. PHP-FPM log:

Code Select Expand


[28-Jan-2020 08:41:11] WARNING: [pool smf] child 18840 exited on signal 7 (SIGBUS - core dumped) after 205.327441 seconds from start
[28-Jan-2020 08:42:55] WARNING: [pool smf] child 5444 exited on signal 7 (SIGBUS - core dumped) after 1984.657430 seconds from start
[28-Jan-2020 08:44:54] WARNING: [pool smf] child 20837 exited on signal 7 (SIGBUS - core dumped) after 223.403533 seconds from start


Note that two of these pools crashed only a few minutes after they were started. Nginx log:

Code Select Expand


X.X.X.X - - [28/Jan/2020:08:41:11 -0500] "GET /forum/index.php?action=dlattach;topic=27106.0;attach=19514;image;ts=1580005456 HTTP/1.1" 502 182 "https://www.mysite.org/forum/index.php?topic=27106.0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0"
Y.Y.Y.Y - - [28/Jan/2020:08:42:55 -0500] "GET /forum/index.php?action=dlattach;topic=27106.0;attach=19520;image;ts=1580005519 HTTP/1.1" 502 182 "https://www.mysite.org/forum/index.php?topic=27106.msg182695" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; EIE10;ENUSWOL; rv:11.0) like Gecko"
Y.Y.Y.Y - - [28/Jan/2020:08:44:54 -0500] "GET /forum/index.php?action=dlattach;topic=27082.0;attach=19550;image;ts=1580087566 HTTP/1.1" 502 182 "https://www.mysite.org/forum/index.php?topic=27082.0" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; EIE10;ENUSWOL; rv:11.0) like Gecko"


Are there any PHP FPM configuration variables that need to be looked at? Right now I'm doing this:

Code Select Expand


memory_limit = 256M
opcache.memory_consumption=256


[sah62]

In the absence of any other suggestions, I've been tweaking the value of pm.max_requests in my pool config file to respawn processes. I haven't seen any crashes for almost 24 hours now, so this might be a reasonable work-around. I still don't know if the crashes are an FPM issue, an SMF issue, or something else, but this seems to be working for me. An optimal value for anyone else will require experimentation to find the right number of requests.

Code Select Expand


; The number of requests each child process should execute before respawning.
; This can be useful to work around memory leaks in 3rd party libraries. For
; endless request processing specify '0'. Equivalent to PHP_FCGI_MAX_REQUESTS.
; Default Value: 0
pm.max_requests = 25


[d3vcho]

What version of SMF are you using? Do you have Image Proxy enabled?

[sah62]

What version of SMF are you using? Do you have Image Proxy enabled?

2.0.17, Image Proxy is not enabled.

[sah62]

I'm still experiencing these occasional errors. I installed the debug symbols for PHP 7.2, forced some core dumps, and learned that the crashes were happening in the Zend OPcache. Reinstalling the module didn't eliminate the crashes, so now I'm going to see what happens when I disable the opcache.

[sah62]

I'm not sure why, but installing the APCu extension seems to have finally solved this problem for me.