I do have a very strange problem where I cannot find any way for debugging. I have a server running Arch Linux, Apache 2.4 and PHP versions 7.4, 8.0 and recent 8.1 as php-fpm. All PHP configurations are identically (modules and configs). But 8.1 has a very strange behaviour regarding php-curl.
I install this php (curltest.php) on my server:
<?php
// this was the originally intended code:
// define ('HTTP_URL', 'https://'.$_SERVER['HTTP_HOST'].'/curltest.php?test=1');
// this doeas not work, too:
define ('HTTP_URL', 'https://'.$_SERVER['HTTP_HOST'].'/any_php_script.php');
// all commented following lines are for testing if $_GET is the cause
// if (empty($_GET['test'])) {
$curlHandle = curl_init();
$fp = fopen('/tmp/error.txt', 'w+');
curl_setopt_array($curlHandle, array(
CURLOPT_URL => HTTP_URL,
CURLOPT_VERBOSE => true,
CURLOPT_STDERR => $fp,
CURLOPT_FAILONERROR => false,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_CONNECTTIMEOUT => 5,
CURLOPT_TIMEOUT => 5,
CURLOPT_RETURNTRANSFER => true
));
$response = curl_exec($curlHandle);
if (curl_errno($curlHandle)) {
$response = 'Curl error: ' . curl_error($curlHandle);
}
curl_close($curlHandle);
//} else {
$response = 'Erfolg';
//}
echo $response;
The script works perfectly if I run it with PHP 7.4 and 8.0. If I use PHP8.1 I get a "timeout" - no response, nothing in the logs. I dug a bit deeper and tested with calling a text or html file instead of the script itself: this works flawlessly. If I call another php on the same domain the issue pops up again. But if I call a php on the same server but a different domain it works! So the problem only exists:
when using PHP 8.1 (8.1.13-1)
calling a php script which resides on the same domain as my testscript
So it cannot be a dns issue (calling text or html files is working). And it cannot be a problem that I cannot access php via a php-curl: using different domain (on the same server running the same php version) is also working. Any hint for debugging this is welcome.
As already stated I tested with different file types and different domains (on the same server using the same php version). I increased php log level and activated curl to be verbose writing STDERR to file output without success.
You are getting a timeout because you are running in an endless loop. It looks like in that one setup the $_GET variable is not populated and so the if condition always evaluates to true, opening another curl request.
The reason for this can be a misconfiguration of variables_order (php.ini) or FPM parameters (sometimes in a file like fastcgiparams or fastcgi_param params in nginx).
You can verify this by putting a small message after opening the error log:
fwrite($fp, 'Opening socket ' . (string)$curlHandle . PHP_EOL);
Make sure you got G in ini_get('variables_order');
Related
https://www.mediawiki.org/wiki/Extension:Push
is an extension that will let you push pages from one MediaWiki toanother.
As documented in
https://www.mediawiki.org/wiki/Topic:Saza08eh1dcygs3c
I had trouble getting this to work with target Mediawikis that use SSL and self signed certificates.
Push would choke up with the message: Dateitransfer fehlgeschlagen: Authentifizierung auf https:///api.php ist fehlgeschlagen.
The issue is now solved and I am adding this question to make the solution available for Stackoverflow users to find.
First as outlined in https://www.mediawiki.org/wiki/Topic:Saza08eh1dcygs3c
https://github.com/BITPlan/Push/commit/cf393a32423bd8ae07af50a5587f847f20cfb9b9
has a commit with a few extra lines for error handling. The resulting message is:
Authentication at .../mediawiki/api.php(http-curl-error:SSL certificate problem: unable to get local issuer certificate) failed.
This is a major improvement in handling such situations - especially the debugging works better.
So the natural attempt to add:
ini_set("openssl.cafile","BITPlanValidCerts.pem")
ini-set("curl.cainfo","BITPlanValidCerts.pem")
didn't work - you have to set these in the php.ini file. A curl https:// test then works. But still no go with Mediawiki and the push extension.
https://github.com/BITPlan/Push/commit/3f68dd36a65ff6ad8c68df807c2c32311073dae4
fixes the issue by adding the curl.cainfo php ini setting to the curl options
getHttpRequest( $target,
array(
array(
'postData' => $requestData,
'postData' => $requestData,
'method' => 'POST',
'method' => 'POST',
- 'timeout' => 'default'
+ 'timeout' => 'default',
+ 'caInfo' => ini_get('curl.cainfo')
)
)
);
);
The same fix might also apply to similar situations where the upgrade advice:
https://www.mediawiki.org/wiki/Manual:Extension_support/1.17/ExtUpgrading
has been followed. MWHttpRequest will handle the caInfo option if it is supplied see https://doc.wikimedia.org/mediawiki-core/master/php/HttpFunctions_8php_source.html
I'm trying to connect to a Magento instance using the SOAP API v2, and although I can see the wsdl when I visit http://www.domain.loc/api/v2_soap?type=soap&wsdl=1 in my browser, I am unable to execute the login() call, an error is always thrown.
Code:
$options = array(
'trace' => 1,
'cache_wsdl' => WSDL_CACHE_NONE,
//'location' => 'http://www.domain.loc/index.php/api/v2_soap?wsdl=1',
'soap_version' => SOAP_1_2,
'connection_timeout' => 120,
'exception' => 0,
'encoding' => 'utf-8',
);
try {
$client = new soapClient('http://www.domain.loc/api/v2_soap?type=soap&wsdl=1', $options);
$client->login('username', 'password');
//$result = $client->catalogProductList($sessionId);
//$result = $client->call($session, 'catalog_product.list');
var_dump($client);
} catch (SoapFault $e) {
var_dump($e);
}
Which yields "SoapFault: looks like we got no XML document"
When I uncomment the location option I get "SoapFault: Wrong Version"
When I view the wsdl file, I see the soap:address location set as
<port name="Mage_Api_Model_Server_HandlerPort" binding="typens:Mage_Api_Model_Server_HandlerBinding">
<soap:address location="http://www.domain.loc/index.php/?SID=7o7mn7iiu9tr8u1b9163r305d4dp1l1jrcn1hmnr34utgnhgb6i0&type=soap"/>
Which seems incorrect as it is the URL to the homepage, with the SID and a query param.
Magento version EE1.14
Things I have tried:
Disable local modules - no change
Using Zend_Soap_Client - no change
Various different URL configurations - tried everything under the
sun, no change
Using SOAP v1 - same results
Tried using this on a remote instance instead of my local - same
result
Checked phpinfo - yes SOAP is installed
Tried debugging - When I turn on Xdebug and run my test script it
seems to prevent the script from even running. Browser just
indicates loading forever
Tried to uncomment line in .htaccess to rewrite RewriteRule
^api/([a-z][0-9a-z_]+)/?$api.php?type=$1 [QSA,L] - No change
(yes mod rewrite is on and working)
Tried fetching wsdl and saving locally and passing it into SOAP
client constructor - no change
Anyone know how to troubleshoot this? I see several threads with these errors, but either unanswered or have tried their solution and it did not work in this case. Why is my location in the wsdl incorrect? Any help at all would be appreciated. Thanks!
I'm trying to get logstash working in a centralised setup using the docs as an example:
http://logstash.net/docs/1.2.2/tutorials/getting-started-centralized
I've got logstash (as indexer), redis, elasticsearch and standalone kibana3 running on my web server. I then need to run logstash as an agent on another server to collect apache logs and send them to the web server via redis. The number of agents will increase and the logs will vary, but for now I just want to get this working!
I need everything to run as a service so that all is well after reboots etc. All servers are running Ubuntu.
For all logstash instances (indexer and agent), I'm using the following init script (Ubuntu version, second gist):
https://gist.github.com/shadabahmed/5486949#file-logstash-ubuntu
For running redis as a service, I followed the instructions here:
http://redis.io/topics/quickstart (Installing redis more properly)
Elasticsearch is also running as a service.
On the web server, running redis-cli returns PONG correctly. Navigating to the correct Elasticsearch URL returns the correct JSON response. Navigating to the Kibana3 url gives me the dashboard, but no data. UFW is set to allow the redis port (at the moment from everywhere).
On the web server, my logstash.conf is:
input {
file {
path => "/var/log/apache2/access.log"
type => "apache-access"
sincedb_path => "/etc/logstash/.sincedb"
}
redis {
host => "127.0.0.1"
data_type => "list"
key => "logstash"
codec => json
}
}
filter {
grok {
type => "apache-access"
pattern => "%{COMBINEDAPACHELOG}"
}
}
output {
elasticsearch {
embedded => true
}
statsd {
# Count one hit every event by response
increment => "apache.response.%{response}"
}
}
From the agent server, I can telnet successfully to the web server IP and redis port. logstash is running. The logstash.conf file is:
input {
file {
path => "/var/log/apache2/shift.access.log"
type => "apache"
sincedb_path => "/etc/logstash/since_db"
}
stdin {
type => "example"
}
}
filter {
if [type] == "apache" {
grok {
pattern => "%{COMBINEDAPACHELOG}"
}
}
}
output {
stdout { codec => rubydebug }
redis { host => ["xx.xx.xx.xx"] data_type => "list" key => "logstash" }
}
If I comment out the stdin and stdout lines, I still don't get a result. The logstash logs do not give me any connection errors - only warnings about the deprecated grok settings format.
I have also tried running logstash from the command line (making sure to stop the demonised service first). The apache log file is correctly outputted in the terminal, so I know that logstash is accessing the log correctly. And I can write random strings and they are output in the correct logstash format.
The redis logs on the web server show no sign of trouble......
The frustrating thing is that this has worked once. One message from stdin made it all the way through to elastic search. That was this morning just after getting everything setup. Since then, I have had no luck and I have no idea why!
Any tips/pointers gratefully received... Solving my problem will stop me tearing out more of my hair which will also make my wife happy......
UPDATE
Rather than filling the comments....
Thanks to #Vor and #rutter, I've confirmed that the user running logstash can read/write to the logstash.log file.
I've run the agent with -vv and the logs are populated with e.g.:
{:timestamp=>"2013-12-12T06:27:59.754000+0100", :message=>"config LogStash::Outputs::Redis/#host = [\"XX.XX.XX.XX\"]", :level=>:debug, :file=>"/opt/logstash/logstash.jar!/logstash/config/mixin.rb", :line=>"104"}
I then input random text into the terminal and get stdout results. However, I do not see anything in the logs until AFTER terminating the logstash agent. After the agent is terminated, I get lines like these in the logstash.log:
{:timestamp=>"2013-12-12T06:27:59.835000+0100", :message=>"Pipeline started", :level=>:info, :file=>"/opt/logstash/logstash.jar!/logstash/pipeline.rb", :line=>"69"}
{:timestamp=>"2013-12-12T06:29:22.429000+0100", :message=>"output received", :event=>#<LogStash::Event:0x77962b4d #cancelled=false, #data={"message"=>"test", "#timestamp"=>"2013-12-12T05:29:22.420Z", "#version"=>"1", "type"=>"example", "host"=>"Ubuntu-1204-precise-64-minimal"}>, :level=>:info, :file=>"(eval)", :line=>"16"}
{:timestamp=>"2013-12-12T06:29:22.461000+0100", :level=>:debug, :host=>"XX.XX.XX.XX", :port=>6379, :timeout=>5, :db=>0, :file=>"/opt/logstash/logstash.jar!/logstash/outputs/redis.rb", :line=>"230"}
But while I do get messages in stdout, I get nothing in redis on the other server. I can however telnet to the correct port on the other server, and I get "ping/PONG" in telnet, so redis on the other server is working..... And there are no errors etc in the redis logs.
It looks to me very much like the redis plugin on the logstash shipper agent is not working as expected, but for the life of me, I can't see where the breakdown is coming from.....
I've set up a logstash on a CentOS server to read from our production web servers IIS logs via a CIFS mount.
input {
file {
path => "/mnt/remote/server*/W3SVC1/ex*.log"
type => "w3c"
}
}
filter {
grok {
type => "w3c"
match => [ "message", "%{HOST:hostname} %{IP:hostip} %{WORD:method} %{URIPATH:request} (?:%{NOTSPACE:param}|-) %{NUMBER:port} (?:%{USER:username}|-) %{IPORHOST:clientip} %{NOTSPACE:httpver} (?:%{NOTSPACE:agent}|-) %{NOTSPACE:cookies} %{NOTSPACE:referer} %{IPORHOST:webhostname} %{NUMBER:status} %{NUMBER:time-taken}" ]
}
}
But, after initially reading an initial burst of logs, it just dies.
(The elevated data afterwards is from a different data source)
I tried a hack from Jordan from this thread, but it doesn't seem to work
tail -f /mnt/remote/server1/W3SVC1/ex130913.log | java -jar logstash.jar
We are purposely avoiding installing Java/Logstash on our front-end web servers because of security issues. So, can you think of a way to make this work?
I have a PHP script that keeps stopping at the same place every time and my browser reports:
The connection to the server was reset
while the page was loading.
I have tested this on Firefox and IE, same thing happens. So, I am guessing this is an Apache/PHP config problem. Here are few things I have set.
PHP.ini
max_execution_time = 300000
max_input_time = 300000
memory_limit = 256M
Apache (httpd.conf)
Timeout 300000
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 0
Are the above correct? What can be causing this and what can I set?
I am running PHP (5.2.12.12) as a
module on Apache (2.2) on a Windows
Server 2003.
It is very likely this is an Apache or PHP issue as all browsers do the same thing. I think the script runs for exactly 10 mins (600 seconds).
I had a similar issue - turns out apache2 was segfaulting. Cause of the segfault was php5-xdebug for 5.3.2-1ubuntu4.14 on Ubuntu 10.04 LTS. Removing xdebug fixed the problem.
I also had this problem today, it turned out to be a stray break; statement in the PHP code (outside of any switch or any loop), in a function with a try...catch...finally block.
Looks like PHP crashes in this situation:
<?php
function a ()
{
break;
try
{
}
catch (Exception $e)
{
}
finally
{
}
}
This was with PHP version 5.5.5.
Differences between 2 PHP configs were indeed the root cause of the issue on my end. My app is based on the NuSOAP library.
On config 1 with PHP 5.2, it was running fine as PHP's SOAP extension was off.
On config 2 with PHP 5.3, it was giving "Connection Reset" errors as PHP's SOAP extension was on.
Switching the extension off allowed to get my app running on PHP 5.3 without having to rewrite everything.
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"
It's an old post, I know, but since I couldn't find the solution to my problem anywhere and I've fixed it, I'll share my experience.
The main cause of my problem was a file_exists() function call.
The file actually existed, but for some reason an extra forward slash on the file location ("//") that normally works on a regular browser, seems not to work in PHP. Maybe your problem is related to something similar. Hope this helps someone!
I'd try setting all of the error reporting options
-b on error batch abort
-V severitylevel
-m error_level
and sending all the output to the client
<?php
echo "<div>starting sql batch</div>\n<pre>"; flush();
passthru('sqlcmd -b -m -1 -V 11 -l 3 -E -S TYHSY-01 -d newtest201 -i "E:\PHP_N\M_Create_Log_SP.sql"');
echo '</pre>done.'; flush();
My PHP was segfaulting without any additional information as to the cause of it as well. It turned out to be two classes calling each other's magic __call() method because both of them didn't have the method being called. PHP just loops until it's out of memory. But it didn't report the usual "Allowed memory size of * bytes exhausted" message, probably because the methods are "magic".
I thought I would add my own experience as well.
I was getting the same error message, which in my case was caused by a PHP error in an exception.
The culprit was a custom exception class that did some logging internally, and a fatal error occurred in that logging mechanism. This caused the exception to not be triggered as expected, and no meaningful message to be displayed either.