Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.

If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping

Answers may be delayed for posts that do not include sufficient information.

Internal Server Error on uploading pdf

edited August 2013 in Troubleshooting
When we try to upload a pdf, we now get this error:
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

From our logs:
[Fri Aug 23 14:46:39 2013] [error] [client] Premature end of script headers: php54.cgi, referer:
[Fri Aug 23 14:46:39 2013] [error] [client] File does not exist: /home/boxeldermuseum/, referer:

We don't seem to have a suhosin problem (our phpinfo is at, but this is a recent problem after moving some other things around (moving some other websites we host on the same server to other users). Photos still upload just fine - only pdfs have a problem (and they're small pdfs - 58 KB and thereabouts). (We're running 1.3, schema version 79 - we've been hoping 1.4 will be ready soon!)

I have checked permissions, they're at 755 for the media directory. Help?


  • The "premature end of script headers" message means that PHP itself is crashing in the middle of the request, and that you're running PHP is a CGI module (separate process), as opposed as a module within the web server.

    This is all to say that beyond knowing that you're crashing, that error doesn't tell us much. And PHP isn't supposed to crash, so if it is we're left to cast about semi-randomly for solutions.

    Since this is specific to PDFs, we have a clue where to look. First stop, go into app.conf and set these two settings to a non-zero value:

    dont_use_imagemagick_to_identify_pdfs = 1
    dont_use_graphicsmagick_to_identify_pdfs = 1

    Here's the text in app.conf above those two, which explains why they exist:

    # If you have ImageMagick or GraphicsMagick installed and PDFs are being inexplicably rejected try setting the corresponding
    # option to 1. It has been observed that ImageMagick chokes on some PDFs. Setting this option will force CA to use Zend_PDF
    # to identify uploaded PDF's, which often resolves the issues at the expense of greater memory consumption.
  • I've made that change, still no luck.
    I also changed to PHP 5.4 fastcgi, in hopes that might help, but no luck there either. It seems like it's got to be something to do with whatever is processing the pdfs, since even much larger images work fine. (I've also tried putting the pdfs of the server via ftp and using the media import to pull them in, and that stalls out too.)
  • What's the PHP memory limit on the server?
  • memory_limit is set as 128M (and that's the default with Dreamhost's php), but I think they kill processes (per user) somewhere around the 100MB limit.
  • That might be it. I assume you're uploading some really trivial PDFs to test with? Not huge ones?
  • They're only tiny because they're just pdfs of text (transcripts of oral histories).
    Yesterday afternoon our host responded to my queries on what might be going on with this:
    "Our apologies for the delay in responding to your request and concerns. We have been dealing with an issue where the current process limit (FCGID) was causing the Apache web service to become semi-responsive; sites would become slow or unusable. This was a difficult case to investigate due to many red herrings and the fact that the web service would be online, just not fully functional. As of now, we believe we have found a solution to alleviate this problem by raising the process count limit, but only to a point where it won't be adversely affecting server performance. We're monitoring this change and we appreciate your patience while we fully resolve this case. It may take several hours for this change to go live, but please let us know if this issue is ongoing tomorrow."

    It's now tomorrow, and it is still not working, but I'm thinking it is a hosting quirk, not a CA quirk.

    (From looking at resource logs, it looks like PHP 5.4 is using about 99.9% of the memory we're allowed, even when we're not doing anything in CA. Since our pawtucket instance is not high traffic, I don't think that's the issue either. Although - what hoops to I need to jump through if I move the pawtucket instance to a different user? (My host tracks memory usage by user, not account, so that would allow me to categorically determine at any instant how much of a load we should be putting on things on the backend.)
  • It should run fine under another user so long as that user has write permissions to the directories that require it.
  • What processes would be handling (only) pdfs (i.e. not also handling jpegs, docs, other media)? Still only pdfs are crashing, and I suspect our host may have changed something that could only be affecting them. So far, the response from our host (Dreamhost) has basically been a shrug. (On another topic, we're in the market for a new host. Suggestions welcome.)
  • I'd have to see this server to say anything of use about this, I'm afraid.
  • As I mentioned in the other thread, changing to a new host solved this problem without any other changes. I'm not sure what Dreamhost changed that screwed this up, but we're fixed now.
Sign In or Register to comment.