php died after 4.2.3 / 6.2 update

Discussion in 'General' started by bobykus, Jun 10, 2013.

  1. bobykus

    bobykus Member

    We use suEXEC Daemon php

    ] Possible runaway process, PPID: 9222, PID: 31516, reqCount: 3, process time: 161, checkpoint time: 161, start time: 177
    2013-06-10 07:50:52.872 [STDERR] [Thread debugging using libthread_db enabled]
    2013-06-10 07:50:53.174 [STDERR] 0xb77e9420 in __kernel_vsyscall ()
    2013-06-10 07:50:53.318 [STDERR] #0 0xb77e9420 in __kernel_vsyscall ()
    2013-06-10 07:50:53.318 [STDERR] #1 0x004b37fb in poll () from /lib/libc.so.6
    2013-06-10 07:50:53.318 [STDERR] #2 0x00646389 in Curl_select () from /usr/lib/libcurl.so.3
    2013-06-10 07:50:53.318 [STDERR] #3 0x0063e336 in Curl_perform () from /usr/lib/libcurl.so.3
    2013-06-10 07:50:53.319 [STDERR] #4 0x0063e759 in curl_easy_perform () from /usr/lib/libcurl.so.3
    2013-06-10 07:50:53.319 [STDERR] #5 0xb747b2f3 in zif_curl_exec (ht=1, return_value=0xb1ff5dc,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
    at /usr/local/lsws/phpbuild/php-5.3.25/ext/curl/interface.c:2320
    2013-06-10 07:50:53.319 [STDERR] #6 0x08301f5c in zend_do_fcall_common_helper_SPEC (execute_data=0xa58c64c)
    at /usr/local/lsws/phpbuild/php-5.3.25/Zend/zend_vm_execute.h:322
    2013-06-10 07:50:53.319 [STDERR] #7 0x082daef3 in execute (op_array=0xb22f7f0)
    at /usr/local/lsws/phpbuild/php-5.3.25/Zend/zend_vm_execute.h:107
    2013-06-10 07:50:53.320 [STDERR] #8 0xb74a958e in zend_oe ()
    from /usr/local/lsws/lsphp53/lib/php/20090626/ZendGuardLoader.so
    2013-06-10 07:50:53.320 [STDERR] #9 0x0b22f7f0 in ?? ()
    2013-06-10 07:50:53.320 [STDERR] #10 0x0b2048b4 in ?? ()
    2013-06-10 07:50:53.321 [STDERR] #11 0xbf8345f8 in ?? ()
    2013-06-10 07:50:53.321 [STDERR] #12 0x082d56ae in _get_zval_cv_lookup (ptr=0xfffffdfc, var=1000, type=1)
    at /usr/local/lsws/phpbuild/php-5.3.25/Zend/zend_execute.c:219
  2. NiteWave

    NiteWave Administrator

    try to disable ZendGuardLoader.so in php.ini, see if it gets fixed.
  3. bobykus

    bobykus Member

    What if I need it? Can I load ioncube loader with out Zend Guard?
  4. NiteWave

    NiteWave Administrator

    so far I've not heard of which php script not working because of disable ZendGuardLoader.

    ioncube loader alone should be ok.

    if you have to use ZendGuardLoader.so, you may have to modify the php source code. and it seems not an issue specific to litespeed, also happen with apache.
    for complete detail, please refer
    http://www.litespeedtech.com/support/forum/archive/index.php/t-5765.html
  5. bobykus

    bobykus Member

    OK, another server another problem


    2013-06-10 11:10:41.247 [STDERR] [Thread debugging using libthread_db enabled]
    2013-06-10 11:10:41.625 [STDERR] 0xb775c420 in __kernel_vsyscall ()
    2013-06-10 11:10:43.019 [STDERR] Cannot access memory at address 0xbf273a8c
    Quitting: ptrace: No such process.


    2 of 3 php daemons are running. 3d is unavailable....
  6. webizen

    webizen New Member

    it means the php process just exits (could be it reaches the max request count) which is not necessarily a problem.
  7. bobykus

    bobykus Member

    Great, but why 3d php suexec daemon gone...?
    I did not hear any thing about Zend Guar and php 5.3.25 incompatibility.
    Have you added some new parameters to new lsapi which causing
    php suexec daemon stop or so? And how to investigate the reason?
    Lets say I know it should be a 3 daemons

    ps ax| egrep '/usr/local/lsws/lsphp52|/usr/local/lsws/lsphp53|/usr/local/lsws/lsphp54' | grep -v grep
    11382 ? SN 0:00 lsphp -c /usr/local/lsws/lsphp53/etc/php.ini
    11384 ? SN 0:01 lsphp -c /usr/local/lsws/lsphp52/etc/php.ini
    11386 ? SN 0:00 lsphp -c /usr/local/lsws/lsphp54/etc/php.ini

    and sddnly I see only two.

    11384 ? SN 0:01 lsphp -c /usr/local/lsws/lsphp52/etc/php.ini
    11386 ? SN 0:00 lsphp -c /usr/local/lsws/lsphp54/etc/php.ini

    Scripts with php53 handler just give 500 error or so.
    Where I have to look at, what I have to check or trace? In my case only restart helps.
  8. webizen

    webizen New Member

    Assuming each daemon is for each php5* handler, each lsphp daemon process should be different, ie, lsphp52, lsphp53, and lsphp54, etc. You can _not_ have one lsphp binary act as different php version by reading different php.ini. the lsphp binary has to be different. That should be a good starting point.

    BTW, what's your server platform? control panel? cloudlinux?
  9. bobykus

    bobykus Member

    It is not the same binary, so I am at good point

    ps ax| egrep '/usr/local/lsws/lsphp52|/usr/local/lsws/lsphp53|/usr/local/lsws/lsphp54' | grep -v grep
    7507 ? SN 0:03 lsphp -c /usr/local/lsws/lsphp53/etc/php.ini
    7509 ? SN 0:03 lsphp -c /usr/local/lsws/lsphp52/etc/php.ini
    7510 ? SN 0:00 lsphp -c /usr/local/lsws/lsphp54/etc/php.ini


    lsof -p 7507
    COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
    lsphp 7507 root cwd DIR 252,0 4096 793094 /usr/local/lsws/lsphp53/bin
    lsphp 7507 root rtd DIR 252,0 4096 2 /
    lsphp 7507 root txt REG 252,0 12947131 795376 /usr/local/lsws/lsphp53/bin/lsphp
    ...
    lsof -p 7509
    COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
    lsphp 7509 root cwd DIR 252,0 4096 886021 /usr/local/lsws/lsphp52/bin
    lsphp 7509 root rtd DIR 252,0 4096 2 /
    lsphp 7509 root txt REG 252,0 9811029 886018 /usr/local/lsws/lsphp52/bin/lsphp
    ...
    lsof -p 7510
    COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
    lsphp 7510 root cwd DIR 252,0 4096 984139 /usr/local/lsws/lsphp54/bin
    lsphp 7510 root rtd DIR 252,0 4096 2 /
    lsphp 7510 root txt REG 252,0 26175742 984152 /usr/local/lsws/lsphp54/bin/lsphp

    ...


    Yes, we cloud linux.
  10. bobykus

    bobykus Member

    To my guess with php orphans collection you killing suexec daemons.
    Usually suexec daemon process gone away after


    2013-06-11 07:10:03.185 [STDERR] [Tue Jun 11 07:10:03 2013
    ] Possible runaway process, PPID: 21885, PID: 21861, reqCount: 1, process time: 161, checkpoint time: 161, start time: 161


    But I have no details yet. Do you think it is safe to switch back to 4.2.2 with phps built for new lsapi?
  11. NiteWave

    NiteWave Administrator

    it should be ok.
  12. bobykus

    bobykus Member

    Doesnt help.
    In log


    No request delivery notification has been received from LSAPI process group [-1], possible run away process.

    and then after

    onnection to [uds://tmp/lshttpd/lsphp52.sock.23348] on request #0, confirmed, 0, associated process: -1, running: 0, error: Resource temporarily unavailable!

    Means daemon gone...
    PHP was rebuild for 6.2 with exactly the same option as it was before for 6.1...

Share This Page