php died after 4.2.3 / 6.2 update

bobykus

Well-Known Member
#1
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
 

bobykus

Well-Known Member
#5
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....
 

bobykus

Well-Known Member
#7
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

Well-Known Member
#8
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

Well-Known Member
#9
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

Well-Known Member
#10
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?
 

bobykus

Well-Known Member
#12
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...
 
Top