I've been getting intermittent error 500 messages when running php scripts using imagick to maniplulate images. One script was working fine 95% of the time processing a few images... now since I tried using the same script to batch process 78 images in a directory and write 78 thumbnails to another directory, it fails 100% of the time. I'm not even getting an error 500 message anymore. I restarted Apache but that did not fix the problem. I had several attempts at processing 78 images and the script never got beyond writing about 66 or 67 images before giving error 500 messages. And now, as I say, there is not even an error 500 message - dead.
From the Apache error log:
[Mon May 11 01:31:22 2009] [notice] mod_fcgid: process /home/auto-software/public_html/index.php(6454) exit(communication error), get stop signal 9Other scripts appear to be running ok... I'll try rebooting the server EC2 instance via my Amazon Web Services control panel.
rebooting the EC2 instance didn't help. It appears that none of my imagick scripts will work now - not even very simple test scripts.
If your script takes a long time to return, it could be timing out.
I'm not sure off-hand how to adjust the timeouts. Virtualmin has some knobs for that, though I don't know which would matter here.
--
Check out the forum guidelines!
while I was having problems with the error 500 messages, I tried to solve the problem of never getting more than about 67 images processed, by trying this line of code in my script:
[code:1]$im->setResourceLimit( Imagick::RESOURCETYPE_MEMORY, 8 );[/code:1]
I experiment by changing the 8 to 16, then 32... that was when I think I may have killed Imagick to death... I wonder if there is a way to revive Imagick? I'm puzzled why rebooting the EC2 instance didn't bring it back to life.
It's possible the correct value had been cached. Or a few other things.
However, I'd recommend what Joe suggested -- try increasing some timeouts. Both for PHP script processing, as well as for fcgid.
If you want to rule out fcgid as a possible culprit, you could always try moving that Virtual Server from fcgid to CGI. If you're using the Pro version, you can do that in Server Configuration -> Website Options -> PHP script execution mode.
I'd also make sure you have enough memory set aside for PHP scripts in the PHP configuration.
-Eric
<div class='quote'>I experiment by changing the 8 to 16, then 32... that was when I think I may have killed Imagick to death... I wonder if there is a way to revive Imagick? I'm puzzled why rebooting the EC2 instance didn't bring it back to life.</div>
That's superstition. ;-)
ImageMagick and the PHP imagick bindings are not services that can be killed. ImageMagick is a library that is called. Either it works or it doesn't...it is not stateful. (So, if you give it the same input, it will always give the same output.)
That said, other aspects of your application <i>could</i> be broken. Since things are probably running as a FastCGI service, it could entirely be possible to design a program such that it will always run out of memory after running for a short while and processing a few images. It wouldn't be ImageMagick's fault if you did so, though.
That's not to say there can't be bugs in ImageMagick or imagick. Just want to make sure you're thinking about the problem in a reasonable light, and not thinking you can "break" ImageMagick the library.
--
Check out the forum guidelines!
Oh, and restarting Apache is all you ever need to do to restart the FastCGI servers. Restarting the whole server (or EC2 instance, in this case) is superstitious rebooting. You don't want no truck with superstition when it comes to systems management. It just makes your life harder than it needs to be.
--
Check out the forum guidelines!
I shall try those things, as I'm sure lack of memory and timeouts are all part of the problem - but for the moment Imagick appears to be completely broken. None of the most basic and simple Imagick scripts will run. I just got this Apache error message from trying to run a really simple Imagick script that never gave me any problems before:
<div class='quote'>[Mon May 11 03:40:55 2009] [warn] mod_fcgid: stderr: PHP Fatal error: Uncaught exception 'ImagickException' with message 'Wand contains no images `MagickWand-11' @ magick-image.c/MagickSetImageFilename/9363' in /home/auto-software/public_html/test/polarize1a.php:5
[Mon May 11 03:40:55 2009] [warn] mod_fcgid: stderr: Stack trace:
[Mon May 11 03:40:55 2009] [warn] mod_fcgid: stderr: #0 /home/auto-software/public_html/test/polarize1a.php(5): Imagick->__construct(Array)
[Mon May 11 03:40:55 2009] [warn] mod_fcgid: stderr: #1 {main}
[Mon May 11 03:40:55 2009] [warn] mod_fcgid: stderr: thrown in /home/auto-software/public_html/test/polarize1a.php on line 5</div>
Somebody else appears to be having a similar problem here: [url]http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=1368...
Looks like I may also need to roll back to Imagick 2.2.2 or 2.2.1
Anyway it's 3:45am here so I must get to bed now and get back to this tomorrow. Cheers, Rob.
hehe - talking of superstition, the 78 image files are for a tarot card app on facebook ;-)
Well I think I'm mostly ontop of both problems now:
1. virtual disk space had all been used up - I noticed a red warning in Virtualmin about disk space. Half the battle for me is knowing where to look to solve problems - now I understand Apache error logs are a good first place to check, I can be more confident in acting like I know what I'm doing.
2. increasing memory allowance may have helped... I tried GCI instead of FCGId, then changed back to FCGId, and managed to write all 78 files for the first time. Just to be sure, I tried it 2 more times, and all 78 files got written, though one of the runs ended the script with an error 500 message before it could echo 'images resized.' Very close shave, that time.
So it seems that stuff is working more or less normal, as it should now, though I'll keep an eye out for any more intermittent error 500s - those would be a real pain if they don't go away.
Seems that using Imagemagick to learn classes, constructors, destructors and OOP, is a very hard way to study - especially when I'm so totally clueless conceptualising the overall stack. Anyway, facebook users ought to be happy with what I'm going to bring them, even if I'm still a million miles from creating an ajax interface to web based image manipulation :-)
Sounds like you might need to increase the memory limit for this virtual server. There's a php.ini for each user in ~/etc/php*. Edit that and set the memory_limit to something larger. 32M or 64M is probably a good start.
Since it sounds like you're new to object oriented development, you might be leaving your objects in memory rather than letting then be destroyed. This could lead to leaks. It could also just be that you've got a bigger workload than will fit into memory. The default memory limit in PHP is something like 8M which is pretty small for processing images.
--
Check out the forum guidelines!
ah, yes - I set the memory to 32M - I'll try 64M. Also, I checked my script and found <b>$image->destroy();</b> does not destroy the object. <b>var_dump($image);</b> outputs: <b>object(Imagick)#1 (0) { }</b> which appears to be an empty object, which I guess is good enough.
I'm using Virtualmin Pro, and that makes life easy when making changes to the php.ini file... the only problem i have with it is remembering where to find stuff in such a vast sea of menu options (actually a good thing).
I think I'm ok with disk space - I set it to unlimited - but now I can't find it in the menu to set it to a sensible amount. I think I'm ok with memory. I'll read up on it to find out the maximum theoretical and real memory available. I think I'm ok on php script timeouts... though I don't really understand the difference between maximum input parsing times and maximum execution times.
In Webmin I've set the global php.ini maximum memory to 32M... so am I correct in thinking that the 64M maximum I set in the Virtualmin php.ini for the site my image manipulation script sits on, will actually be overridden by the global setting of 32M?
ah, yes - I set the memory to 32M - I'll try 64M. Also, I checked my script and found <b>$image->destroy();</b> does not destroy the object. <b>var_dump($image);</b> outputs: <b>object(Imagick)#1 (0) { }</b> which appears to be an empty object, which I guess is good enough.
I'm using Virtualmin Pro, and that makes life easy when making changes to the php.ini file... the only problem i have with it is remembering where to find stuff in such a vast sea of menu options (actually a good thing).
I think I'm ok with disk space - I set it to unlimited - but now I can't find it in the menu to set it to a sensible amount. I think I'm ok with memory. I'll read up on it to find out the maximum theoretical and real memory available. I think I'm ok on php script timeouts... though I don't really understand the difference between maximum input parsing times and maximum execution times.
In Webmin I've set the global php.ini maximum memory to 32M... so am I correct in thinking that the 64M maximum I set in the Virtualmin php.ini for the site my image manipulation script sits on, will actually be overridden by the global setting of 32M?
o crickey I really have been blundering along in the dark all this time. Ouch, I can think of a whole bunch of mistakes I've made in my settings over the last couple of months... time I got busy fixing them.
<div class='quote'>In Webmin I've set the global php.ini maximum memory to 32M... so am I correct in thinking that the 64M maximum I set in the Virtualmin php.ini for the site my image manipulation script sits on, will actually be overridden by the global setting of 32M?</div>
No. What you set in Webmin is not a "global" setting. It is effectively a default for new virtual servers (because that php.ini is copied to new virtual servers, with a few substitutions), and it is also the configuration for any scripts running under mod_php (which is generally none, in a virtual hosting environment...and many people even disable mod_php altogether, so those resources aren't wasted).
Only one php.ini is ever in effect in a given application. If you're using CGI or FastCGI execution mode, it will be the php.ini found in the users home.
--
Check out the forum guidelines!