[wp-trac] [WordPress Trac] #58202: php-fpm7.4: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868.

[WordPress Trac]

#58202: php-fpm7.4: time limit exceeded `Operation canceled' @
fatal/cache.c/GetImagePixelCache/1868.
--------------------------+-----------------------
 Reporter:  dsar          |       Owner:  antpb
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  6.2.3
Component:  Media         |     Version:  6.2
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by densityapps):

 Just wanted to add a comment here to hopefully provide further clarity on
 the issue.

 The reason that the update from
 [https://core.trac.wordpress.org/changeset/55404] caused this breakage is
 that the Imagick timeout setting begins counting from its first
 instantiation within the PHP process. As we know, many server
 configurations are setup to spawn a few PHP processes and reuse them over
 many requests, only spawning new processes when needed. So, by forcing the
 Imagick timeout value to align with the PHP timeout value, after a couple
 of requests, you're effectively setting the Imagick timeout to a value
 that has already elapsed, which then times out, causing that PHP process
 to exit. The server will replace that PHP process with a new one, starting
 the whole process over again.

 I hope this information is helpful, and that the issues can be patched
 very soon. In the meantime the only way to correct this issue on an
 affected site is to comment out the Imagick::setResourceLimit call in
 class-wp-image-editor-imagick.php.

 Side Note: The default Imagick timeout value is something like 18
 quintilion seconds. If the goal is to avoid a PHP timeout while Imagick is
 processing, a better approach might be to instead override the PHP timeout
 whenever an Imagick process is started, to ensure that the Imagick process
 will always complete before a PHP timeout can occur. Though, I can see
 some scenarios where this might cause other issues. I don't know if the
 original goal of the change is something that really can/should be
 addressed from the WordPress side of things. It seems like it could only
 really be properly addressed from an Imagick update.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58202#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform