wp-cli / media-command

Imports files as attachments, regenerates thumbnails, or lists registered image sizes.
MIT License
44 stars 41 forks source link

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

Open drzraf opened 2 years ago

drzraf commented 2 years ago

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

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: https://github.com/wp-cli/wp-cli/issues/4974 Ref: https://github.com/Imagick/imagick/issues/333

bgabler commented 2 years ago

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

danielbachhuber commented 1 year ago

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

drzraf commented 1 year ago

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 commented 1 year ago

@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.