SitePoint Sponsor

User Tag List

Results 1 to 4 of 4

Thread: PHP dying

Hybrid View

  1. #1
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    PHP dying

    I have a PHP script that resizes an image, but when I try to access this page, it seems to get partway through processing the page, then the PHP process handling the request dies. I receive in the browser the output of the script as far as it got.

    Other php pages work okay.

    I'm running PHP using spawn-fcgi to spawn the PHP processes, on Ubuntu.

    To try and debug it, I added the following to my php.ini:

    Code:
    log_errors = on
    error_log = /home/djeyewater/logs/php-errors.log
    and modified the spawn-fcgi init script to start PHP like so:

    Code:
    $FCGI_DAEMON -s $FCGI_SOCKET -C $PHP_FCGI_CHILDREN -P $FCGI_PIDFILE -- $FCGI_PROGRAM -c /home/djeyewater/webapps/php_fcgi/lib/php.ini 2>>/home/djeyewater/logs/php-fcgi-err.log
    Not sure if that is the correct way to record stderr from spawn-fcgi?

    Anyway, after restarting php I got no errors (from the page I'm having problems with) recorded in the php error log or the spawn-fcgi stderr file.
    In the server error log I get the following, which doesn't really tell me anything except that PHP died:
    Code:
    2010/01/12 15:29:33 [error] 7654#0: *15 readv() failed (104: Connection reset by peer) while reading upstream, client: 127.0.0.1, server: www.photosite.com, request: "POST /admin/upload.xhtml HTTP/1.0", upstream: "fastcgi://unix:/home/djeyewater/webapps/spawn-fcgi/php-fastcgi.sock:", host: "www.photosite.com", referrer: "http://www.photosite.com/admin/upload.xhtml";
    Could anyone advise me on how to debug this error, or how to fix it?

    Thanks

    Dave

  2. #2
    SitePoint Addict
    Join Date
    Aug 2007
    Location
    St. Louis, MO.
    Posts
    206
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Not sure about those errors but the first place I would look is your max memory setting in php.ini. If its the default setting resizing large pictures can easily blow that limit and stop php.

  3. #3
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    I run Ubuntu in a VM, so I gave it 4GB of RAM, and added
    Code:
    memory_limit = 3584M
    to the php.ini file, and confirmed this setting by viewing a phpinfo() page.

    But php is still dying and I still get around the same length of response back (i.e. not the full page) from the server. When I use top with a refresh rate of 1 second to view the php processes, I can't see the memory usage going up at all - one of the processes just seems to die when this particular php script is run.

    Oh - I think I've found the problem now. The script isn't working even with very small images, so seems not to be a memory problem. If I remove all Imagick stuff (used to resize the image) then the page works okay. But when the script contains
    Code:
    $thumb = new Imagick($originalImg);
    then PHP will die. The output sent to the browser is less than where PHP gets to before it dies. I presume this is due to PHP holding info in the buffer when it dies.

    It would be nice to know why Imagick is causing PHP to die, but for the moment I'll just try re-compiling PHP without Imagick and then compile Imagick as an extension to see if that works.

    Dave

  4. #4
    SitePoint Zealot
    Join Date
    Dec 2008
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    As per my last post, I've re-compiled PHP without Imagick and then compiled Imagick as an extension, activated it, and the script is now working fine.

    Thanks for the help binarysys.

    Dave


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •