[SOLVED] HTTP POST failed: HTTP 500 Internal Server Error
|
jason@barbanet
Joined: 2012-07-02
Posts: 23 |
Posted: Fri, 2012-07-06 08:18
|
|
This item was discussed in the locked thread http://gallery.menalto.com/node/101913. I would like to raise the topic again. After upgrade to Debian Squeeze on my web server, the uploadapplet malfunctions. After upgrade and patch of both gallery remote - including applets - and uploadapplet applets, the uploadapplet at least executes. But after successful upload of one or two, I get the error message in the subject. The corresponding error messages in the apache2 error.log are [Fri Jul 06 10:56:40 2012] [error] [client 10.0.12.118] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /usr/share/gallery2/modules/exif/lib/exifer/makers/olympus.inc on line 81 Also, please see http://gallery.menalto.com/node/107295, where this error first was posted. /jason EDIT: Fault in php.ini skipped logging. Fixed that, and now I have results. |
|
Posts: 8339
try disabling the exif module and try again.
-s
Posts: 23
Without the EXIF module both Uploadify and uploadapplet performs OK. But without the EXIF module I get the upload date as capture date, not the actual capture date
Do you know of a update/patch of the EXIF module?
/jason
Posts: 1642
It still seems it is your server setup that is the issue.
"...modules/exif/lib/exifer/makers/olympus.inc on line 81" from your error log refers to "$data=hexdec($data);"
"hexdec" is an internal PHP function but it is hanging your installation (Maximum execution time of 30 seconds exceeded).
Since it seems all these issues started since your OS upgrade and bearing in mind that you had a bad php.ini setup before, I'll say you should look into your OS upgrade again and perhaps hire someone to do it for you.
In any case, you should post any other similar issues you may have to a forum dealing with servers and server setups ... maybe Debian's support forum since your issues are related to your server setup.
A good question to ask the Debian people is why hexdec causes PHP to hang since you upgraded. They should be able to take things forward from there.
Good luck!
--
dakanji.com
Posts: 23
Thanks supssidr and Dayo for valuable comments. Since the only application that malfunctioned after the upgrade was/is Gallery upload it was the natural starting point of the debug process.
/jason
Posts: 1642
That's logical.
Having done that, everything so far seems to point to problems with the OS upgrade.
All the best with fixing it and don't forget to come back to post the answer when you get it.
You might want to supply the server/debian folks the error messages and the specified files from the Exif module to help them along.
--
dakanji.com
Posts: 23
Re-activating this thread. Have contacted debian support. No answer as of yet.
In the meantime I have found that disabling all datafields in the EXIF/IPTC administration form doesn't change things; The same error still exits. I have also found that by totally deactivating the EXIF/IPTC module not only does upload of photos work, but also is the displaying of already stored/uploaded photos much faster. Is the EXIF/IPTC module used also when photos are displayed?
I have also found that I on my server have two different catalogs for Gallery2: /usr/share/gallery2 and /usr/share/gallery2.new. The latter is the older according to date and time stamps. Is this in any way negative for the performance of the EXIF/IPTC module or the whole application?
/jason
Posts: 23
I humbly dispute.
Debugging the module olympus.inc - I use an Olympus camera - it can be shown that whenever I display a photo the function formatOlympusData is called repeteadly until the execution timelimit is hit. And, when I upload photos, the number of times formatOlympusData is called from the function parseOlympus - that is the content of the variable $num - is 4949(!) and thus the function formatOlympusData is called accordingly ...
formatOlympusData must be called from different modules, but anyway too many times. There can't be 4949 tags, 49 tags seams more like it.
Hope this can help you help me.
/jason
Posts: 1642
We will get to this one later
Yes it is
The big clue here is the location "/usr/share/".
This tells me you have installed your Gallery using your distro's (Debian) package installer. This has been found in many cases to be associated with problems as it would appear that the packagers often add tweaks/hacks to the application to make it run out of deep server locations such as "/usr/share/" WHICH IT IS NOT DESIGNED TO RUN FROM.
This is all when and good when the application is being actively maintained by the packager but once it is not and the distro starts getting updated without corresponding updates to the added tweaks/hacks, things start to fall apart. Add that to having multiple installations on top of each other and you can see the potential for problems.
G2 is a web application for which the recommended installation procedure is simple. Download the files from the link in the top right corner of every page on this site, copy to the document root of your site, navigate to the site in your browser and follow the simple instructions. It is tried and tested over hundreds of thousands of installations. Needs no tweaks and/or hacks.
Now, I don't know what exactly ails your installation but once it turns out that you have used a package installer to install it, all bets are off and you will need to wait for Debian support to get back to you.
--
dakanji.com
Posts: 23
OK.
I would be most grateful to know what module calls the function formatOlympusData in olympus.inc when displaying photos. I also would like to know if uninstalling the debian package and installing Gallery2 with the installer in any way affects the database.
/jason
Posts: 8339
@jason, did you share a phpinfo link w/ us somewhere?
does your php have exif support?
-s
All New jQuery Minislideshow for G2/G3
Posts: 23
Not in this thread.
http://barbafarfar.barbanet.com/gallery/phpinfo.php
How do I find out? My php installation came along with Debian Squeeze as a package.
/jason
EDIT: changed URL to phpinfo
Posts: 8339
FAQ: What information is required when I ask for help in the forums?
please remove the link to your php.ini and replace it w/ a link to your phpinfo as described in the above FAQ
-s
All New jQuery Minislideshow for G2/G3
Posts: 23
done that
/jason
Posts: 23
As stated above, when performing the piece of code below found in olympus.inc as a part of function parseOlympus, $num contains the value 4949. Problably the substr() function is extracting the wrong bytes from $block. Or $block is not containing the correct data field.
//Get number of tags (2 bytes)
$num = bin2hex(substr($block,$place,2));$place+=2;
The string $block begins with
OLYMPUS II
and $place contains 10, where the two characters "II" are found. the ASCII code for I is hex 49. And "II" could be interpreted as little endians according to a standard document.
/jason
Posts: 8339
Your php is compiled w/ exif support.
Though I've never cracked open the exif module(until now) I'd assume it would rely on php's exif extension.
Yours appears to be the same v. as mine.
It could be that olympus has changed its format in the 9yrs since olympus.inc has been written.
You may want to checkout the exif project to see if there is an updated library for olympus.
olumpus.inc is was not written by the gallery team and unless you find another gallery user who has had a similar issue, you won't likely find help here for it.
-s
All New jQuery Minislideshow for G2/G3
Posts: 1642
Try replacing your olympus.inc file with this version.
(save old version with diff name and change extension of new to .inc)
--
dakanji.com
Posts: 8339
that looks like the same version same w/ the last release from the project http://www.offsky.com/software/exif/index.php
-s
All New jQuery Minislideshow for G2/G3
Posts: 1642
Not sure, the guy said he stopped dev in 2005, said the zenphoto people will maintain it and the file from zenphoto was apparently last updated in October 2009.
Didn't check the details of the package on his site though.
--
dakanji.com
Posts: 1642
Just checked the file on his site and the zenphoto one is different particularly the "parseOlympus" function which is apparently the problem function according to the OP.
The old file set seems to be the same as the G2 one
--
dakanji.com
Posts: 23
Did that, and it helped while displaying photos. The number of tags is set to 73. But unfortunately upload doesn't even try the functions in olympus-inc. Just getting error reports. Nothing is uploaded. I have tried both Uploadify and the Upload applet.
/jason
Posts: 1642
You might need to download the whole set from zenphoto and rename the individual files to match the G2 structure.
You could also see what is triggering the errors from your logs.
Alternatively, you could try to just change the problem function with the updated one if it is an easy change.
--
dakanji.com
Posts: 23
My son did this, and it solved the problem both with uploading and displaying. The debian package for Gallery2, version 2.3.2.dfsg-1, most contain old, outdated EXIF moules/files. This bug is reported to debian.org.
Thanks for support.
/jason
Posts: 1642
Actually, this is a Gallery2 issue. The exifer library packed with the exif module appears to be out of date.
It looks like the debian packager is still actively maintaining G2 and they may of course fix this at their end but these sorts of fixes by packagers is what sometimes leads to issues down the line.
Fortunately the issue can be fixed despite G2' status since it is just a matter of updating a module.
Maybe one for suprsidr to look into as updating the G2 plugin repo is a dark art.
--
dakanji.com