i've got a problem setting up my couchbase server on my new macbook.
I have installed Couchbase 3.0.1 and i am running OS X 10.10
I can login to the webconsole. But there it always tells me my server on 127.0.0.1 is down/pending. I can't get it to run properly.
I already checked the log, but can't get any idea out of it.
One error which appears again and again:
[stats:error,2014-10-31T10:06:11.844,ns_1#127.0.0.1:<0.2019.0>:stats_collector:handle_info:124]Exception in stats collector: {exit,
{{bad_return_value,
{stop,{error,couldnt_connect_to_memcached}}},
{gen_server,call,
['ns_memcached-obd_data',
{stats,<<>>},
180000]}},
[{gen_server,call,3,
[{file,"gen_server.erl"},{line,188}]},
{ns_memcached,do_call,3,
[{file,"src/ns_memcached.erl"},{line,1401}]},
{stats_collector,grab_all_stats,1,
[{file,"src/stats_collector.erl"},{line,84}]},
{stats_collector,handle_info,2,
[{file,"src/stats_collector.erl"},
{line,116}]},
{gen_server,handle_msg,5,
[{file,"gen_server.erl"},{line,604}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}
Anyone an idea how to solve my problem and get the server started?
Or is there any common known problem already?
Related
I used to have PhpStorm working brilliantly on my computer. No browser extensions. I could put breakpoints anywhere, go to some URL in browser, hit enter and then I would automatically be taken to breakpoint in given file. Files in project would open up automatically as I stepped through code.
Now, it is a total mess.
First here is my Xdebug info in the xdebug.ini (I don't specify anything Xdebug related in the php.ini):
zend_extension=/usr/local/php5/lib/php/extensions/no-debug-non-zts-20151012/xdebug.so
[xdebug]
xdebug.remote_enable=on
xdebug.default_enable=on
xdebug.remote_port=9000
xdebug.remote_host=localhost
If I run php -v I get
PHP 7.0.15 (cli) (built: Feb 13 2017 10:30:54) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.15, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans
iMac:xdebug-2.7.2 $
phpinfo() shows corresponding values set based on my .ini.
In PhpStorm I have PHP CLI set to 7.0, it is showing Xdebug 2.7.2.
Curious about that "Can't load xdebug" message, but php -v doesn't show same message. At first I had zend_extension defined in both php.ini and the xdebug .ini and would see that message when doing php -v but after removing from php.ini the message went away from php -v.
I have no idea if I need to do anything under Debug settings in Build, Deployment, but here is what is there by default:
Also, I have my project set to sync with a remote server but for debugging I don't want to use path mappings. That is how I had it before and PhpStorm messages about debug session ending and no path mappings found was never a problem.
Here is my Run->Config
In the past, I didn't worry about a start URL. No matter what URL I entered in browser it triggered debugging.
And here is what I have tried regarding path mappings:
I did that to see if it would fix things, but no.
My gut feeling says it is either a problem with Xdebug settings, my run->config, or the fact that I am using a virtual host and somewhere there is a localhost entry causing a problem.
So I am at a loss. If I select Listen for incoming... and go to URL, the focus does not go to PhpStorm with current breakpoint. I see in browser that things stopped and I go to PhpStorm and see that debug was triggered. But the second I hit step over or step into the debugging just ends.
Anything glaringly wrong with what I am doing?
Edit: Here is what I see in the xdebug log:
[89603] W: Creating socket for 'dev.courses.com:9000', poll success, but error: Operation now in progress (19).
[89603] E: Could not connect to client. :-(
[89603] Log closed at 2019-10-21 10:42:37
[89603]
[89603] Log opened at 2019-10-21 10:42:37
[89603] I: Connecting to configured address/port: dev.courses.com:9000.
[89603] W: Creating socket for 'dev.courses.com:9000', poll success, but error: Operation now in progress (19).
[89603] E: Could not connect to client. :-(
[89603] Log closed at 2019-10-21 10:42:37
Not sure the specifics of the error... Maybe this hints at something? The question I have is where in the config do I specify localhost vs my virtual host alias? Maybe that is what is messing things up?
You can find out what Xdebug is trying to do by using the xdebug.remote_log=/tmp/xdebug.log setting. This log will indicate which connection attempts are being made, and why they succeed or not.
Ok, so this turned out to be an xdebug issue, though not obvious at first.
Originally I didn't think to check the PHPStorm log. But the PHPStorm log showed
Argument for #NotNull parameter 'remoteFileUrl' of com/jetbrains/php/debug/xdebug/debugger/XdebugDriver.onBreak must not be null
Searching above error took me to
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360001498520-xdebug-works-only-with-first-line
Turns out my version of PHPStorm is known to not work with xdebug 2.7 so I downgraded to 2.6.1 and all is well :-)
thanks,
Brian
in the new version 1.3 of ORION if I make a GET http request on the root of the server, the broker immediately breaks down.
I set the logs at DEBUG level and de trace levels to 0-255, the execution seems to be correct. There is no trace which help us undestand what is happening before the crash.
We tried in diferent ORION installations(docker from docker HUB, on CENTos OVM)
Anyone knows what is happening?
Thanks in advance.
I just did a quick test and I can confirm that this is a bug. A recent change in the detection of the API version uses the URI PATH without first checking for empty URI PATH. The result is a segmentation fault. The fix is more than easy. Will be fixed in the next few days and included in the next release (1.4.0).
I have configure ejabberd server 2.1.10 with mysql database integration,mod_admin_extra module and mod_xmlrpc module.
Issues is ejaberd admin commands like add_rosteritem, delete_rosteritem are notworking with xml_rpc.
When we use direct command line like,
*root#ejabberdserver:~# ejabberdctl add_rosteritem admin domain.com karthik domain.com karthik none both*
it will work and store in to database.
but same command does not work with xml_rpc.
xml_rpc does not return any error, it retun {ok,{response,[0]}}
But it does't store database.
Any permission issue?
Any body please help!!!!!
I meet the similar issue recently, and turn out the root cause was there a bug in (svn)ejabberd_module source code, and this was reported in https://github.com/processone/ejabberd-contrib/issues/22 and fixed in ejabberd-contrib,
So I suggest you download the source https://github.com/processone/ejabberd-contrib and rebuild the mod_admin_extra.
http://localhost:3000/genre
I'm using Instant Rails, I'm introducing scaffolding for the first time ever.
So everything looks like its working fine, I did my own RoR page etc, today i come in today and when I go to localhost:3000 I get the following error message:
Oops! Google Chrome could not connect to localhost:3000
Any suggestions of what I should check would be greatly appreciated. So far I know to confirm that:
the windows host file connects 127.0.0.1 to localhost
I've had an update to this the Mongrel server doesnt start properly with the new app I have created, rather than an open window, it just runs a script and closes the window without confirmation that it has started.
Thanks in advance.
here is the details of the Mongrel error:
C:\Users\Will\Desktop\instantrails\rails_apps\talewiki>mongrel_rails start -p 30
00
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/activerecord-2.0.
2/lib/active_record/connection_adapters/abstract/connection_specification.rb:217
:in establish_connection': development database is not configured (ActiveRecord
::AdapterNotSpecified)
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/acti
verecord-2.0.2/lib/active_record/connection_adapters/abstract/connection_specifi
cation.rb:208:inestablish_connection'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:234:in initialize_database'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:94:inprocess'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:49:in send'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/rail
s-2.0.2/lib/initializer.rb:49:inrun'
from C:/Users/Will/Desktop/instantrails/rails_apps/talewiki/config/envir
onment.rb:13
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/site_ruby/1.8/ruby
gems/custom_require.rb:27:in gem_original_require'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/site_ruby/1.8/ruby
gems/custom_require.rb:27:inrequire'
... 9 levels...
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/mong
rel-1.1.2-x86-mswin32/bin/../lib/mongrel/command.rb:212:in run'
from C:/Users/Will/Desktop/instantrails/ruby/lib/ruby/gems/1.8/gems/mong
rel-1.1.2-x86-mswin32/bin/mongrel_rails:281
from C:/Users/Will/Desktop/instantrails/ruby/bin/mongrel_rails:19:inlo
ad'
from C:/Users/Will/Desktop/instantrails/ruby/bin/mongrel_rails:19
As it appears your Database has not been configured. Check out the APP_ROOT/config/database.yml file and find if you have created the database that corresponds to the development environment. Once you setup the DB, your code should run fine.
I have a webapp that segfaults when the database in restarted and it tries to use the old connections. Running it under gdb --args apache -X leads to the following output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212868928 (LWP 16098)]
0xb7471c20 in mysql_send_query () from /usr/lib/libmysqlclient.so.15
I've checked that the drivers and database are all up to date (DBD::mysql 4.0008, MySQL 5.0.32-Debian_7etch6-log).
Annoyingly I can't reproduce this with a trivial script:
use DBI;
use Test::More tests => 2;
my $dbh = DBI->connect( "dbi:mysql:test", 'root' );
sub test_db {
my ($number) = $dbh->selectrow_array("select 1 ");
return $number;
}
is test_db, 1, "connected to db";
warn "restart db now";
getc;
is test_db, 1, "connected to db";
Which gives the following:
ok 1 - connected to db
restart db now at dbd-mysql-test.pl line 23.
DBD::mysql::db selectrow_array failed: MySQL server has gone away at dbd-mysql-test.pl line 17.
not ok 2 - connected to db
# Failed test 'connected to db'
# at dbd-mysql-test.pl line 26.
# got: undef
# expected: '1'
This behaves correctly, telling me why the request failed.
What stumps me is that it is segfaulting, which it shouldn't do. As it only appears to happen when the whole app is running (which uses DBIx::Class) it is hard to reduce it to a test case.
Where should I start to look to debug this? Has anyone else seen this?
UPDATE: further prodding showed that it being under mod_perl was a red herring. Having reduced it to a simple test script I've now posted to the DBI mailing list. Thanks for your answers.
What this probably means is that there's a difference between your mod_perl environment and the one you were testing via your script. Some things to check:
Was your mod_perl compiled with the same version of Perl
Are the #INC's the same for both
Are you using threads in your mod_perl setup? I don't believe DBD::mysql is completely thread-safe.
I've seen this problem, but I'm not sure it had the same cause as yours. Are you by chance using a certain module for sending mails (forgot the name, sorry) from your application? When we had the problem in a project, after days of debugging we found that this mail module was doing strange things with open file descriptors, then forked off another process which called the console tool sendmail, which again did strange things with file descriptors. I guess one of the file descriptors it messed around with was the connection to the database, but I'm still not sure about that. The problem disappeared when we switched to another module for sending mails. Maybe it's worth a look for you too.
If you're getting a segfault, do you have a core file greated? If not, check ulimit -c. If that returns 0, your system won't create core files and you'll have to change that. If you do have a core file, you can use gdb or similar tools to debug it. It's not particularly fun, but it's possible. The start of the command will look something like:
gbd /usr/bin/httpd core
There are plenty of tutorials for debugging core files scattered about the Web.
Update: Just found a reference for ensuring you get core dumps from mod_perl. That should help.
This is a known problem in old DBD::mysql. Upgrade it (4.008 is not up to date).
There's a simple test script attached to https://rt.cpan.org/Public/Bug/Display.html?id=37027
that will trigger this bug.