This is my first attempt to consume MongoDB. I've got Mongo running:
ps -ef | grep [m]ongo
mongodb 11023 1 0 Jun24 ? 00:00:03 /usr/lib/mongodb/mongod --config /etc/mongodb.conf
And the error comes as the result of doing
Datastore.save( stuff ); // (pseudo code)
The error:
Jun 27, 2011 3:20:29 PM com.mongodb.DBTCPConnector fetchMaxBsonObjectSize
WARNING: Exception determining maxBSON size using0
java.io.IOException: couldn't connect to [russ-elite-book/127.0.1.1:27017] bc:java.net.ConnectException: Connection refused
at com.mongodb.DBPort._open(DBPort.java:206)
at com.mongodb.DBPort.go(DBPort.java:94)
at com.mongodb.DBPort.go(DBPort.java:75)
at com.mongodb.DBPort.findOne(DBPort.java:129)
at com.mongodb.DBPort.runCommand(DBPort.java:138)
...
Note that I'm using 127.0.0.1:27017 for my connection, which works to the Mongo shell. Also, I get the admin page in the browser using http://localhost:28017.
Profuse thanks for any and all ideas!
I ran into the same issue because I upgraded my mongo using brew. To fix this issue. Look for the conf file(which might not be located in the bin directory where you start your mongodb from)
/usr/local/Cellar/mongodb-2.2.whatever/mongod.conf, and comment out the "bind_ip" property.
(I think it slightly bad form to answer one's own question, but in fact, the answer turns out to be none of those suggested. Nevertheless, my profuse thanks to all of them. When answering a question, one needs to be able to assume it's based on correctly installed and working software. I did not have that.)
I installed MongoDB using the Ubuntu Software Center. It worked from the shell and from the browser as noted elsewhere in this question. However, it did not work from Java (nor from Django either).
The problem, despite what it said in the Java stack trace, was simply "connection refused."
The solution is to install it from proper Mongo sources and not to trust the Ubuntu repository.
(Yes, this also frequently happens to other products obtain from there too, like Eclipse, but you know it's such a nice service that you want to trust it.)
If you want to read how I installed what then worked, check out http://www.javahotchocolate.com/tutorials/mongodb.html.
I had the same problem, but my solution was different. I was using "localhost" as the host name and changing it to "127.0.0.1" fixed it.
Most likely the Java driver cannot connect to the address specified.
Make sure that you can connect to that address 127.0.1.1:27017 using the shell and run "db.isMaster()".
Maybe it is an issue of 127.0.1.1 vs 127.0.0.1.
It turns out that it is an issue with the Java MongDB driver.
There are two solutions:
Using version 2.8 or higher of the Java driver.
Edit the configuration files and if it contains the line bind_ip = 127.0.0.1 or bind_ip = localhost, comment it out.
Eating humble pie...
As I showed in my comment to Russ Bateman's own answer, it seemed like an issue with the Ubuntu package at first. The real reason is that the config file that comes with it does define a value for bind_ip...
I ran into the same issue because I installed my mongo using apt-get. Here's how to fix it:
Find your mongod.conf file. In Ubuntu 14.04, it's /etc/mongod.conf
Open mongod.conf file and command the line bindIp = 127.0.0.1
Restart mongod
It appears that this is a security issue or an invalid url. If you used the default configuration, you should be able to access the http://yourmachine:28017. See if you can navigate to the admin page from this url. If you are able to navigate to the admin url, just replace the port number with 27017 in your app. It should work.
It's hard to say without seeing your .conf file contents. One thing I would recommend is running the mongo shell and seeing if you can connect, query, and write from it. This will help isolate server vs. a java client issue. Additionally it may give you a different form of the error which may be a hint.
Are you setting --port in your .conf file?
For me, it was a completely different solution. I am using Spring MVC framework, and all I had to do is to confirm that the configuration XML files are saying the same thing in the /target folder as well as the non-target folders. Once that was adjusted, everything worked. The problem was that everything worked when run from a STS, but when deployed, I had the mentioned error.
Related
Mongoose 5.10.10 - Windows 10+WSL2 - Mongo 4.4.1
Worked fine before the MongoDB upgrade. I dynamically acquire Windows IP in Ubuntu on WSL and connect (or try to) on WIN_IP:27017. Connection fails with timout every time. I've tried many combinations of options. Nothing helps. I've had to resort to Mongo in Docker, which works perfectly well, but is sub-optimal for my purposes.
Any ideas?
Thanks.
Could have happened during Mongo upgrade or maybe during Windows upgrade. But several things needed fixing.
Even though the Mongo bin directory has a mongod.cfg with dbPath specified correctly, mongod tries to start with dbPath = c:\data\db. This is how it would be set up on a server, I'm told.
I changed mongod's bind ip address to 0.0.0.0 (from 127.0.0.1).
I punched a hole in the firwall specifically for mongod.exe.
One or more of these changes did the trick. Sorry, I don't know if any one or two would have worked.
Had the same problem this week. I'm my case I just figured it out it was WSL version I updated over the weekend. Running wsl --set-version {distro} 1 on the PowerShell did the trick.
I recently installed Manjaro and followed this tutorial: https://snapcraft.io/install/wekan/manjaro to install wekan. Everything went slicker than snot. I registered an account no issues, open the weken webgui at port 8080 without issue, create new lists and cards fine, but when I go to open the cards I create the connection to 127.0.0.1 is refused. Although it doesn't specify a port, I assume this is a call to the mongodb at the default port 27017, but I also opened up 28017 in the firewall.
Although mongo definitely seems to have been installed since I can see it is running, I can't find a mongod*.conf file on the system to verify the default ports.
This is the first time I used “snap” to install anything, and because it all went so seamlessly I have no clue where to start looking to find the issue. Is there a utility in snap where I can find out exactly what was installed to support wekan (webserver, database, etc.) that I can start checking into as potentials sources of issue. Thks.
I'm trying to setup mongodb on my nitrousio nodejs box. Following this tutorial.
When I finish executing this command,
mongo --shell --host $MONGODB_DEVELOPMENT_HOST --port $MONGODB_DEVELOPMENT_PORT
-u $MONGODB_DEVELOPMENT_USERNAME -p $MONGODB_DEVELOPMENT_PASSWORD
$MONGODB_DEVELOPMENT_DB
This happens,
Even though my MONGO_DEVELOPMENT_DB environment variable is set to pest, it tries to connect to test. Not only pest, if I try to connect to any of my DB instances, it always tries to connect to test.
Any idea as to what could be going wrong?
I had something similar recently and it turned our that the config file was overriding some of the parameters. Try to look at /usr/local/mongodb/mongod.conf (on OS X, probably similar on linux)
Ok, terminated the box and created a new one, that fixed it. Guess I messed up the env. variables in my first attempt. Works just fine now.
I had the same problem and I've tried with new boxes(minimum memory and storage) but it didn't work out.
After increasing memory and storage on existing box to maximum I could
(Memory: 640MB and Storage: 1500MB)
I was able to start MongoDB server and Mongo shell.
After starting the mongo shell your session will use the test database by default. For mong details, please refer to MongoDB Doc
I'm not sure if this will give you everything you need but at least I can ensure the mongo command interface works on Nitrous for me. Firstly a bit of background.
The helpful support guy at Nitrous told me that Nitrous only expose ports: 1024 - 10,000 open. The default for mongodb is: 27017. This port seems to be hand coded into the mongo command as well.
On Nitrous, I changed my mongodb.config file to use a port within that range, on the 0.0.0.0 address:
~/.parts/etc/mongodb.conf
bind_ip = 0.0.0.0
port = 7017
See:
default mongodb ports
config file format
Apparently the bind to 0.0.0.0 IP address is not necessary due to Nitrous magic, however I haven't tested that. After re-starting mongodb server:
$ parts stop mongodb
$ # ... edit ~/.parts/etc/mongodb.conf
$ parts start mongodb
$ mongo localhost:7017
Anyway that works for the default database. I expect other (valid, reasonable) command line options should be OK. The 'test' db name is the default, so if you never make a connection it mongodb probably won't even look at the DB Name given.
I am experimenting with the MEAN.io stack on Nitrous, so the config will be a quite different to your example. That said, this command works fine:
$ mongo localhost:7017/mean-dev
To open the mean-dev database. Hopefully setting the port will give you what is needed.
One last thing the mongodb control interface for that port is on the nitrous preview URL with port number +1,000 ==> 8017. I have not discovered how to make the REST API work with the admin interface (yet). Even so, the admin screen shows me that things are looking reasonable.
Good luck /w.
I am new to Mongodb. When I run the following command:
sudo service mongodb start
It shows me "mongodb start/running, process 3566". But when I try to stop by giving the below command:
sudo service mongodb stop
It shows stop: Unknown instance:. Do anybody have any idea how to slove this issue.
And if I give sudo service mongodb restart, I'm getting the below message:
stop: Unknown instance:
mongodb start/running, process 3644
PS: If I'm using just mongod, I could start the server and could connect the mongo shell by giving mongo.
Please suggest me how to fix the issue and how to connect mongo shell after giving service mongodb start. Thanks in advance.
I just ran into this.
Chances are the issue is in your conf file (obviously, since you reinstalled the seeded)
In the mongodb.conf do not set fork = true if calling it as a service. This will prevent the service call from being able to access it with service mongodb.conf status/stop/restart.
Removing a fork=True line, however, will alleviate the issue.
See comments; use the other solution even though this one is accepted.
The reason you get the Unknown instance error is because upstart is tracking the wrong PID for the instance of forked mongod process. But the proper solution to this is not running the process in foreground by removing fork=true line from the config like #GoingTharn suggesting, but rather helping upstart to capture the right PID of the forked process by adding
expect daemon
to the /etc/init/mongodb.conf
I faced exactly the same problem and did the followings:
Removed the file mongod.lock (in my case this file was located at /var/lib/mongodb/)
Used the following command from my mongo client
mongo --repair
And that fixed the issue. It may be noted that I had a system crash prior to this problem appeared. Therefore, what I believe, the problem was caused due to the unclean shutdown of the server demon.
If you are unsure of the reason, you may wish to have a look at the log file (in my case I found it under /var/log/mongodb/). That might give you some useful hints.
Thanks.
I faced it as you had.Maybe it is because my computer crash unexpectedly.I use the command: sudo top(ubuntu), and I found mongo running.I killed it and start mongo.Every thing turns right.
I fixed it by myself. Below is what I did:
apt-get install mongodb
And overwrote .conf file. After that everything works fine. I hope this would help someone.
I tried today to connect to MySQL server and saw that I did'nt have any mysqld.sock anymore, nowhere.
I tried several ways to get it back, but unsuccessfull. I tried to execut a
./mysqld.start in /etc/init.d, but it's also missing.
Should I reinstall mysql, or is there a way to get a socket back ?
try using following command
service mysql start
This will work.
#Nueva, if that doesn't work, reboot the system. I just had an Ubuntu build on EC2 lose its mysqld.sock file, and a simple reboot solved the problem.
Failing that, I've also heard that forcing the connection via tcp instead of localhost has worked for some people. I tried that, but got nothing.