php died after 4.2.3 / 6.2 update

[bobykus]

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

 

[NiteWave]

from /usr/local/lsws/lsphp53/lib/php/20090626/ZendGuardLoader.so

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

 

[bobykus]

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

 

[NiteWave]

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

 

[bobykus]

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....

 

[webizen]

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

 

[bobykus]

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.

 

[webizen]

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.

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?

 

[bobykus]

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.

 

[bobykus]

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?

 

[NiteWave]

Do you think it is safe to switch back to 4.2.2 with phps built for new lsapi?

it should be ok.

 

[bobykus]

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...