我在下面的php函数中遇到了一个奇怪的问题。不幸的是,这是一个特殊的“仅生产”案例。
function requestPost($url, $data)
{
set_time_limit(60);
$output = array();
$curlSession = curl_init();
if($curlSession == false)
syslog(LOG_INFO,"Falied to create a curl sessions");
// Set the URL
curl_setopt ($curlSession, CURLOPT_URL, $url);
// No headers, please
curl_setopt ($curlSession, CURLOPT_HEADER, 0);
// It's a POST request
curl_setopt ($curlSession, CURLOPT_POST, 1);
// Set the fields for the POST
curl_setopt ($curlSession, CURLOPT_POSTFIELDS, $data);
// Return it direct, don't print it out
curl_setopt($curlSession, CURLOPT_RETURNTRANSFER,1);
// This connection will timeout in 30 seconds
curl_setopt($curlSession, CURLOPT_TIMEOUT,30);
//The next two lines must be present for the kit to work with newer version of cURL
//You should remove them if you have any problems in earlier versions of cURL
curl_setopt($curlSession, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($curlSession, CURLOPT_SSL_VERIFYHOST, 1);
//Send the request and store the result in an array
syslog(LOG_INFO,"base.php::requestPost() : BEFORE SENDING CURL ");
$rawresponse = curl_exec($curlSession);
}
PHP 5.3.6 (cli) (built: Mar 17 2011 21:19:28) curl Version : 7.20.1 NSS Version : 3.12.9 apr Version : 1.4.5 Php Version : 5.3.6
这似乎随机挂在curl_exec上。我不是php开发人员所以我不知道从哪里开始。
我注意到当curl请求被“挂起”时,在停止httpd守护程序时它会尝试发送这些请求,因此它们可能会被缓存或卡在httpd服务器中。任何指针都会受到赞赏。
编辑:我设法将堆栈跟踪从Web服务器中删除。
(gdb) where
#0 0x00c15416 in __kernel_vsyscall ()
#1 0x002f522c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x00a73a9d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libc.so.6
#3 0x00b9b869 in PR_WaitCondVar () from /lib/libnspr4.so
#4 0x00809c0f in NSSRWLock_LockWrite_Util () from /usr/lib/libnssutil3.so
#5 0x05e9ae0e in ?? () from /usr/lib/libnss3.so
#6 0x05ebd014 in ?? () from /usr/lib/libnss3.so
#7 0x05ebd60d in ?? () from /usr/lib/libnss3.so
#8 0x05eb0506 in SECMOD_LoadModule () from /usr/lib/libnss3.so
#9 0x05eb047f in SECMOD_LoadModule () from /usr/lib/libnss3.so
#10 0x05e7c007 in ?? () from /usr/lib/libnss3.so
#11 0x05e7c95e in NSS_Initialize () from /usr/lib/libnss3.so
#12 0x008e8609 in ?? () from /usr/lib/libcurl.so.4
#13 0x008e9215 in Curl_nss_connect () from /usr/lib/libcurl.so.4
#14 0x008df9a3 in Curl_ssl_connect () from /usr/lib/libcurl.so.4
#15 0x008bc1fa in Curl_http_connect () from /usr/lib/libcurl.so.4
#16 0x008c44c6 in Curl_protocol_connect () from /usr/lib/libcurl.so.4
#17 0x008c5075 in ?? () from /usr/lib/libcurl.so.4
#18 0x008c58cf in Curl_async_resolved () from /usr/lib/libcurl.so.4
#19 0x008d1b2f in Curl_perform () from /usr/lib/libcurl.so.4
#20 0x008d2a74 in curl_easy_perform () from /usr/lib/libcurl.so.4
#21 0x006b4693 in ?? () from /usr/lib/php/modules/curl.so
#22 0x056e4ac9 in ?? () from /etc/httpd/modules/libphp5.so
#23 0x056bb87e in execute () from /etc/httpd/modules/libphp5.so
#24 0x05693a66 in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#25 0x05639cb6 in php_execute_script () from /etc/httpd/modules/libphp5.so
#26 0x057236b3 in ?? () from /etc/httpd/modules/libphp5.so
#27 0x00dc6421 in ap_run_handler ()
#28 0x00dca166 in ap_invoke_handler ()
#29 0x00dd6fa8 in ap_process_request ()
#30 0x00dd39e8 in ?? ()
#31 0x00dcec71 in ap_run_process_connection ()
#32 0x00ddc44a in ?? ()
#33 0x00ddc7ee in ?? ()
#34 0x00ddd793 in ap_mpm_run ()
#35 0x00db0ab2 in main ()
它似乎陷入了pthread_condition等待状态。有人有线索吗 ? 通过命令行每次都能成功完成相同的请求;所以它确实指向了图书馆。
修改
以下是永远不会发出的电话。
* About to connect() to live.sagepay.com port 443 (#0)
* Trying x.x.x.x... * connected
* Connected to live.sagepay.com (x.x.x.x) port 443 (#0)
* warning: ignoring unsupported value (1) of ssl.verifyhost
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_MD5
* Server certificate:
* subject: CN=live.sagepay.com,OU="Member, VeriSign Trust Network",OU=Authenticated by VeriSign,OU=Terms of use at www.verisign.co.uk/rpa (c)05,OU=Sage,O=Sage (UK) Limited,L=Newcastle Upon Tyne,ST=TYNE AND WEAR,C=GB,serialNumber=x.x.x,OID.x.x.x=Private Organization,OID.x.x.x.x=GB
* start date: Mar 05 00:00:00 2011 GMT
* expire date: Mar 04 23:59:59 2013 GMT
* common name: live.sagepay.com
* issuer: CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US
> POST /gateway/service/vspserver-register.vsp HTTP/1.1^M
Host: live.sagepay.com^M
Accept: */*^M
Content-Length: 664^M
Content-Type: application/x-www-form-urlencoded^M
^M
< HTTP/1.1 200 OK^M
< Date: Wed, 15 Jun 2011 16:11:43 GMT^M
< Server: Microsoft-IIS/6.0^M
< X-Powered-By: ASP.NET^M
< Content-Language: en-GB^M
< Content-Length: 276^M
< Set-Cookie: NSC_wjq-tbhfqbz-dpn-ofx=xxxx;expires=Wed, 15-Jun-2011 16:48:26 GMT;path=/;secure;httponly^M
< ^M
* Connection #0 to host live.sagepay.com left intact
修改 问题出在NSS上,用OpenSSL重新编译curl,还有一些用于依赖的箍(libssh2)&amp;到目前为止似乎工作正常。
干杯!
答案 0 :(得分:9)
在脚本末尾添加以下内容以获取失败原因
if( $rawresponse === false )
syslog( LOG_INFO , "base.php::requestPost() : ".curl_error($curlSession) );
编辑1
这可能是卷曲的内部问题。在所有检查之前,所有服务器运行时都是最新的(至少是php,php-curl和apache)。检查所有日志..... 然后我建议比较几个生产环境或开发/测试环境之间的结果。
最后尝试缩小可以重现您的问题并发布测试用例的完整代码的最小测试用例。
答案 1 :(得分:7)
堆栈跟踪清楚地显示您在NSS加密库中发生的中断,您的libcurl构建用于SSL。
自从您使用的libcurl版本以来,libcurl已经获得了许多与NSS相关的修复,并且您可能也没有使用最新的NSS。我强烈建议您在解决这个问题之前考虑升级到最新和最好的。要调试此问题,我建议您尝试使用同一服务器中的curl命令行重复此问题,并充分利用--trace-ascii命令。
答案 2 :(得分:4)
问题是NSS。我使用OpenSSL重新编译curl,到目前为止它没有显示任何问题。
干杯!
答案 3 :(得分:2)
您是否尝试过安装不同版本的apache和php?你在包经理里有他们吗?如果没有,请尝试手动编译最新的apache,php和curl,看看是否得到相同的结果。
答案 4 :(得分:1)
NSS比OpenSSL或GnuTLS更严格。 Fedora / RHEL curl默认使用NSS而非OpenSSL,并且可以捕获在OSX,Ubuntu等上使用curl时不会出现的错误。
以下是NSS错误代码http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html
的列表[root@mybox ~]# curl -k -v -E /etc/mycert.pem https://127.0.0.1/
* About to connect() to 127.0.0.1 port 443 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* warning: ignoring value of ssl.verifyhost
* NSS error -8054
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
答案 5 :(得分:1)
如果curl_exec
挂起,则可能是因为DNS问题或重定向循环。换句话说,该功能可能没有任何问题,但可能与您的请求的网络路由有关。可能是localhost循环的死锁。
干杯!