imagick intermittent 500 server error

[evenstar7139]

About 50% of the time when I run a script that uses imagick::blurImage it fails and I get this error:

500 Server Error

A misconfiguration on the server caused a hiccup. Check the server logs, fix the problem, then try again.

NOTHING goes in the error logs and this did NOT used to happen--EVER. It just started suddenly, two days ago.

Here's a simple script I put together, to illustrate my point:

<?php 

$image = new Imagick('http://www.mysitenamehere.com/images/bordercollie25.jpg');

$image->blurImage(5,3);
print "success";

?>

If you run it over and over it works about half the time and gives you the error the other half.

I had NEVER seen this error until a couple days ago and now it's happening with every script that uses imagick::blurImage

Any ideas what could be wrong? My host is using ImageMagick 6.7.9-10 2012-10-05

[NogDog]

My first guess would be that the http request for the image is failing for some reason (maybe timing out?). If you save that image to your web host and then access it via the file system (instead of http), do you still have that problem?

[evenstar7139]

Yep.

btw it works 100% of the time if the script doesn't have imagick::blurImage() in it

My scripts never had a problem with that method before. Do you think it's a bug in ImageMagic? However if that's the case, I'm confused, because my host says they haven't updated ImageMagick since last year.

[NogDog]

Try adding a call to set_time_limit() (arg of 0 for no time limit or else a large number of seconds) to see if it's simply PHP timing out?

[evenstar7139]

Added set_time_limit(0); to the beginning of the script and I'm still getting intermittent the error. Same thing happened with set_time_limit(5000000000000);

<?php 
set_time_limit(0);
$image = new Imagick('/home/mywebsitename/public_html/images/bordercollie25.jpg');

$image->blurImage(5,3);
print "success";
?>

Did I do it right? If so, what should I try next?

[NogDog]

try {
    $image = new Imagick('/home/mywebsitename/public_html/images/bordercollie25.jpg');
    $image->blurImage(5,3);
} catch(ImagickException $e) {
    die("<pre>Imagick:\n".print_r($e, true)."</pre>)";
} catch(Exception $e) {
    die("<pre>PHP:\n".print_r($e, true)."</pre>");
} 

[evenstar7139]

Tried that, nothing changed. When it fails I get a 500 internal server error and nothing else.

Something I noticed, though: When it's going to work, the script finishes quickly; when it's not, it spins its wheels for a few seconds and then I get the 500 error.

Anyhoo, do you think my host is at fault? Is there anything they could have done to cause this? I asked them about it and they're swearing up and down it's not them, and that it's my code, but I dunno...I have scripts whose code I haven't touched in a month that worked fine until a couple days ago =\

[NogDog]

Outside of grepping the server logs to see what they say, I'm wondering if it could be some sort of file locking problem. You could try sticking in an $image->destroy(); once you're done with that object, just in case. (I'm at the straw-grasping stage here, so I'm not horribly optimistic.)

[evenstar7139]

Are server logs and error logs two different things? My cPanel lets me view error logs but they never show anything for this error.

And I tried imagick::destroy() and nope it didn't help

[NogDog]

It would be different than the php-errors.log or whatever it's called. This would be the web server (Apache, IIS, whatever) http error log, which you may or may not have access to depending on your hosting plan.

[evenstar7139]

Well, I have multiple error logs. Could it be the one called main error log? I checked it right after seeing my script fail.

I saw a bunch of these:
[Mon Jan 14 19:43:38 2013] [warn] child process 13567 still did not exit, sending a SIGTERM
[Mon Jan 14 19:43:38 2013] [warn] child process 27344 still did not exit, sending a SIGTERM
[Mon Jan 14 19:43:38 2013] [warn] child process 27156 still did not exit, sending a SIGTERM
[Mon Jan 14 19:43:38 2013] [warn] child process 32016 still did not exit, sending a SIGTERM
[Mon Jan 14 19:43:38 2013] [warn] child process 14128 still did not exit, sending a SIGTERM

Then a bunch of these:
[Mon Jan 14 19:43:40 2013] [error] child process 27947 still did not exit, sending a SIGKILL
[Mon Jan 14 19:43:40 2013] [error] child process 27722 still did not exit, sending a SIGKILL
[Mon Jan 14 19:43:40 2013] [error] child process 23565 still did not exit, sending a SIGKILL
[Mon Jan 14 19:43:40 2013] [error] child process 24969 still did not exit, sending a SIGKILL
[Mon Jan 14 19:43:41 2013] [notice] caught SIGTERM, shutting down

This was the last line:
[Mon Jan 14 19:43:41 2013] [internal] (7614) httpd - error_log SIGTERM Received

- - - -

Ran the script again, got the error, and the log looked totally different. This was the only noteworthy thing I saw:
[Mon Jan 14 19:47:35 2013] [error] [client MY IP HERE] Premature end of script headers: js_test.php

That's the script I was running.

[NogDog]

In our continuing quest to find out wtf is going on with IMagick....

From this bug report: https://bugs.php.net/bug.php?id=60946

Try adding this right after you instantiate $image:

$image->setResourceLimit(6, 1); // set max threads to 1 

If that fixes it, I've earned my salary for the day. (If not, I'm about ready to give up. )

[evenstar7139]

Progress! I ran the test script 200 times and it didn't fail. However, when I started running my actual image generator, it got the error on the 3rd try.

Shall I email you the code? I don't want to post it here because sombody might rip it off :P

[NogDog]

Do you do a...

$something = new Imagick() 

...anywhere else in the script? If so, in each case, you'll probably have to follow it up with the same setResourceLimit() on each new such object. Otherwise we'll "talk" tomorrow (already past my bedtime)

[evenstar7139]

Yeah, the script instantiates those objects a bunch of times (like 20).

And woo I think it fixed it. Also it's way faster, now. It was sluggish before and now it's flying.

You get cookies for the day.

--

I'll post again on this thread if it messes up again but so far I've ran it 200 times and it's not had a problem.