time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868.

[drzraf]

php -d max_execution_time=42 $(which wp) eval "echo ini_get('max_execution_time');"
// outputs 42

time php -d max_execution_time=42 $(which wp) media regenerate --only-missing --yes

php7.4: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868.
real	0m30,995s
user	0m27,111s
sys	0m3,571s

Sounds strange at first but this is a limit set by /etc/ImageMagick-6/policy.xml
Eg: <policy domain="resource" name="time" value="84"/> will change the image operation timeout

• The main problem is that ImageMagick time limit applies on the whole run, not on individual image operation.
• Still, the error message is confusing and hopefully wp-cli could do something about that.
• Changing the time limit is possible Imagick::setResourceLimit( Imagick::RESOURCETYPE_TIME, 3*3600);

On a somehow related note: https://core.trac.wordpress.org/ticket/52569 was about the problem of PHP timeout in the middle of an ImageMagick operation.

Ref: wp-cli/wp-cli#4974
Ref: Imagick/imagick#333

[bgabler]

Starting to run into this quite a lot. Was there ever any fix available?

[danielbachhuber]

@drzraf Any recommendations for how WP-CLI might be able to handle this better?

[drzraf]

Not really. We can't even catch the failure consistently. The php-imagick side of the things would definitely needs love and priority (and somehow the WP-core part too). Then only wp-cli could be improved to handle this (maybe by anticipating/resizing the batch/time of image operations to workaround this).

NB: The timeout problem regularly leaves some of my servers with a /tmp full of imagick temporary files (which are not garbage collected), as commented in https://core.trac.wordpress.org/ticket/52569

[danielbachhuber]

@drzraf Ok, thanks for the update. We can leave this leave this open to see if a solution presents itself. I'll also follow along on that core ticket.