php: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1717

[splaquet]

I've been primarily working on other projects and servers lately (w/o cPanel). Within the last week or so, I've run into an odd anomaly that I haven't ever seen.
php: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1717.

I'm on CloudLinux8/CentOS8 w/ Imunify360. My server is running ea-php74 and my user account is running alt-php74

Typically, I do most of my WordPress grunt work w/ WP-CLI.

The first time I experienced this timeout/fail, I thought that it might simply be something related to the user's account I was in. I passed it as a 1-off.

The second time this happened, I was on a different server (same config), brand new hosting account (no limits set in CageFS), and properly configured alt-php selector extensions.

The odd part is that (at least to my knowledge), no alt-php, php, cPanel, CL files have been altered or modified. The only changes have been nightly updates. ...so why is my CLI script timing out at 2 minutes now? As well, why am I now seeing this timeout/fail error message that I've NEVER seen before... on 2 different servers?

I have max_execution_time set to 600s on this account, but it's consistently stopping right around 120s (129s, 132s). I haven't experienced a timeout like this in wp-cli/terminal for as long as I can remember... and that's primarily why I do all my time consuming, grunt work via CLI!

php: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1717.
real 2m9.608s
user 1m9.716s
sys 0m3.614s


php: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1717.
real 2m10.078s
user 1m9.908s
sys 0m3.817s


Anyhow... I'm at a loss here. I'm not finding any reference to that fatal php error (post title), I've checked anything/everything I can think of (alt-php, ea-php, lsapi.conf, etc). I'm not seeing anyone else talking about this on cPanel or CL forums... but, I'm really out of options here. It's been debilitating

 

[splaquet]

UPDATE: I figured I'd run wp-cli using ROOT account, simply working around the time limit and updating file owner/group of regenerated thumbnails. I found this error rather odd, as I haven't seen this error before:
[23-May-2022 17:14:25 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'imagick.so' (tried: /opt/cpanel/ea-php74/root/usr/lib64/php/modules/imagick.so (libMagickWand-6.Q16.so.6: cannot open shared object file: No such file or directory), /opt/cpanel/ea-php74/root/usr/lib64/php/modules/imagick.so.so (/opt/cpanel/ea-php74/root/usr/lib64/php/modules/imagick.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

 

[cPRex]

Hey there! cPanel doesn't install any of the ImageMagick or MagickWand tools by default, so you'd need to manually add those to the system to get them working. Details on how to take care of that can be found here:

How to Install ImageMagick for EA-PHP and ALT-PHP

What is ImageMagick? ImageMagick is software designed to display, convert, and edit raster and vector images. It can be leveraged with PHP by installing the ImageMagick PHP extension on cPanel serv...

support.cpanel.net

Can you try that and see if that helps?

 

[laxbobber]

Following.... we are seeing this error in our nightly WHMCS cron runs:

php: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1716

Probably the wrong place for this (as it's WHMCS-related) but a similar error. It doesn't happen every day for us so I'm still working through it. @splaquet did you work through it?

 

[splaquet]

@splaquet did you work through it?

I haven't, and it doesn't sound as though cPanel staff is going to offer much more support on the issue. While I know that I already had ImageMagick installed (and libs) and previously working, I did go through their cPanel ImageMagick install guide to be safe. But nope... still seeing the same problem.

The odd part is that this NEVER happened, and it only started happening recently. I have zero idea as to what changed, but something definitely did.

 

[cPRex]

@splaquet - feel free to submit a ticket and we can check it out!

 

[Mark Donne]

Hi @splaquet

We have today been notified by a user that they are also experiencing this same problem which started around 1 month ago.

php-cgi: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1717.

Like you we have CloudLinux, although it's v7.9.0, LiteSpeed EWS and we use Imunify 360.

Did you submit a ticket with cPanel and if so, did they find the cause?

 

[splaquet]

Did you submit a ticket with cPanel and if so, did they find the cause?

Mark, I have not submitted a ticket.

 

[cPRex]

@Mark Donne - feel free to submit a ticket!

 

[Mark Donne]

Hi

We did submit a ticket in the end and a very helpful Cody Selzer managed to track down what we believe is the cause of the short timeout.

I will copy and paste his response here for anyone else who encounters this problem.

You may attempt modifying the imagemagick policy, timeout. You can do this editing the file here: /opt/alt/alt-ImageMagick/etc/ImageMagick-7/policy.xml

grep 120 /opt/alt/alt-ImageMagick//etc/ImageMagick-7/policy.xml
<policy domain="resource" name="time" value="120"/>

We increased our value to 480 and the user who originally reported a problem said that they did not get any errors this morning.

<policy domain="resource" name="time" value="480"/>

Hope this helps someone else.

 

[cPRex]

@Mark Donne - thanks for sharing!

 

[splaquet]

grep 120 /opt/alt/alt-ImageMagick//etc/ImageMagick-7/policy.xml
<policy domain="resource" name="time" value="120"/>

Thank you Mark! After editing and implementing that change, my issue immediately went away.

Rex... sounds like something that pushed through from CloudLinux? My files were stamped 4/26, which is quite aligned with right around when I first discovered this issue. (I didn't post when I first noticed the problem, but came to the forums to post when it effected me the second time.)

So, I'd have to assume this is limited to users of CL... and this file also had the same time/date stamp on all of my servers.

 

[cPRex]

I've reached out to them to see if they have any other details on this - I'll let you know when I hear back!

 

[cPRex]

CloudLinux did confirm they made this change because users had requested a timeout option, but they have an internal case open to see if there is a better way to handle that in the future. I can't share that case here because it's on the CloudLinux side of things, but they are aware and working on this now.

 

[splaquet]

CloudLinux did confirm they made this change because users had requested a timeout option, but they have an internal case open to see if there is a better way to handle that in the future. I can't share that case here because it's on the CloudLinux side of things, but they are aware and working on this now.

thank you so much for helping out there. ...yeah, that change of theirs was NO BUENO!!!

 

[cPRex]

It might be best to contact them directly to let them know how it is affecting you and your users so they have additional feedback.