Error setting up listener mongodb

In this MongoDB tutorial, I will explain how I managed to resolve the error “Failed to set up listener: socketexception: address already in use MongoDB”.

When I run the command mongod in my terminal I get the following error message:

socketexception-address already in use

From the error, It is clear that the address or port the MongoDB is trying to start from is already occupied with another instance or some other process.

You can either run the mongod instance in another port or kill the previous instance or the process whichever is using the port reserved for MongoDB instance to start.

We will discuss the following ways to fix this error.

Fix 1 — Kill the instance which is using the PORT reserved for mongo.

First, you have to search for a list of operations running on your machine by typing:

sudo lsof -iTCP -sTCP:LISTEN -n -P

And, then search for mongod command and its PID and type,

sudo kill <mongo_command_pid>

The above command will kill the mongod instance. After that, Start again your mongod instance by typing,

mongod

You can see MongoDB running successfully.

Also, check: MongoDB data directory /data/db not found

Fix 2 — Run mongo instance in another PORT.

In MongoDB, By default running port is 27017. And, you are already running a previous mongo instance in port 27017. So if you don’t want to disturb it then you can run the mongo instance in another port using the following command.

mongod — port 27018

Here, I have used 27018 to run the mongo instance, you can either use the following lists of the default TCP ports used by MongoDB:

Default Port	Description
27017	This is the default port for mongod and mongos instances.
27018	It is the default port when running with –shardsvr runtime operation.
27019	It is the default port when running with –configsvr runtime operation.

Also, read: Select the first element in an array in MongoDB

Conclusion

In short, we can say, we have to either run the mongod instance in another port or kill the previous instance or the process whichever is using the port reserved for MongoDB instance to start.

In this tutorial, we have covered the reason behind getting errors “MongoDB socketexception: address already in use” and fixed the error with two different solutions.

Also, take a look at some more tutorials on MongoDB.

MongoDB compare two fields
MongoDB get collection size
Current date in MongoDB
Display MongoDB data in HTML
Distinct query in MongoDB
MongoDB find string contains

Bijay

I am Bijay having more than 15 years of experience in the Software Industry. During this time, I have worked on MariaDB and used it in a lot of projects. Most of our readers are from the United States, Canada, United Kingdom, Australia, New Zealand, etc.

Want to learn MariaDB? Check out all the articles and tutorials that I wrote on MariaDB. Also, I am a Microsoft MVP.

Источник

Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Erik L

seal-mask

So I noticed that when I run mongod on visual studio code I get this: Failed to set up listener: SocketException: Address already in use, which is strange since I closed all my terminal windows, how can I resolve this?

Eriks-MacBook-Pro:stage_4_start eriklopezramirez$ mongod
2019-02-16T00:28:03.866-0500 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols
 'none'
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] MongoDB starting : pid=3017 port=27017 dbpath=/data/db 64-bit host=Eriks-MacBo
ok-Pro.local
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] db version v4.0.3
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] git version: 7ea530946fa7880364d88c8d8b6026bbc9ffa48c
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] allocator: system
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] modules: none
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] build environment:
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten]     distarch: x86_64
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten]     target_arch: x86_64
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] options: {}
2019-02-16T00:28:03.881-0500 E STORAGE  [initandlisten] Failed to set up listener: SocketException: Address already in use
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] now exiting
2019-02-16T00:28:03.881-0500 I CONTROL  [initandlisten] shutting down with code:48

1 Answer

seal-mask

See this StackOverflow answer on the subject of this bug: Failed to set up listener: SocketException: Address already in use,

My guess is that you’re already running mongo. Two things can’t both run on the same port.

Источник

The compilation environment is: Huawei «elastic cloud server» CentOS Linux+SecureCRT 8.3

The cause of the problem: the bindd in the configuration file mongod.conf is incorrectly filled out.

Should fill in the private ip address, not the public ip address

1, edit the configuration file, modify the bindIp value

Intelligent Recommendation

Spring boot launch error: Protocol Handler Start Failed | Cannot Assign Requested Address: Bind

The SpringBoot project suddenly can’t come, I have been reporting wrong: Caused by: org.springframework.boot.web.server.WebServerException: Unable to start embedded Tomcat server at.

MongoDB startup error 2020-06-16T16:46:13.882+0800 E STORAGE [initandlisten] Failed to set up listener: Socket

mongodb reported an inexplicable error when it started: Failed to create Listener, no space? ? ? But it scared me. Seen after free -m Only 28MB is available. No way to release Um, it is really good, c.

Источник

Mongo replication not working #179

Comments

ashish-kumar-sw commented Oct 30, 2019 •

Mongo replication not working-

Steps to replicate :

change user to root in Dockerfile.

The text was updated successfully, but these errors were encountered:

jotamartos commented Oct 31, 2019

Thanks for using our solution. I just tried to reproduce the issue you reported but couldn’t do so. Taking a quick look to your docker-compose.yml file, I noticed that the «MONGODB_REPLICA_SET_KEY» env variable is missing in all the nodes, that means that the nodes can’t connect to each other as this key is not set. Can you set a value there and retry? You can get more information about the replication here:

You can also have an example here:

However, you should have received a similar error message to this one

We will review the code in our solution to know if there is something we can improve.

javsalgar commented Oct 31, 2019 •

We are going to release a new version of the container with several improvements. I’ll let you know the exact version. Could you confirm that the error still appears with this new container?

ashish-kumar-sw commented Oct 31, 2019 •

Replication succeed after adding root password and replica set key , but I guess this is optional and replication must succeed without these two parameters. (Same is given by the team in https://github.com/bitnami/bitnami-docker-mongodb#setting-up-replication )

@javsalgar I will confirm with the new version, kindly share that.

juan131 commented Nov 1, 2019

but I guess this is optional and replication must succeed without these two parameters

As you can find in the link you shared:

MONGODB_REPLICA_SET_KEY: MongoDB replica set key. Length should be greater than 5 characters and should not contain any special characters. Required for all nodes. No default.

That environment variable is required for all nodes, it’s not optional.

ashish-kumar-sw commented Nov 1, 2019

@juan131 Actually the thing is, initially I followed this only :

So, MONGODB_REPLICA_SET_KEY variable should also be mentioned over there too!

juan131 commented Nov 1, 2019

You’re totally right. The README.md is wrong.

I just created a PR to update it. Please find it in the link below:

Thanks so much for reporting it!

ashish-kumar-sw commented Nov 2, 2019

Replication is still not working, It itself get detached after some time!!

juan131 commented Nov 4, 2019 •

Could you please share the containers logs? I’m unable to reproduce the issue.
Could you also please share the docker-compose.yaml you’re using?

ashish-kumar-sw commented Nov 4, 2019 •

Replication with single secondary is working whereas, for 2 secondary, it is not working.

juan131 commented Nov 4, 2019

I’m afraid you can’t scale your solution using the command below:

Please note that you’re setting the same environment variables for both secondary nodes. The environment variable MONGODB_ADVERTISED_HOSTNAME should be different on each secondary node.

We addressed this issue in the MongoDB helm chart, by automatically calculate the value to set based on the MongoDB pod name. See:

Источник

Mongo replication not working #179

Comments

ashish-kumar-sw commented Oct 30, 2019 •

Mongo replication not working-

Steps to replicate :

change user to root in Dockerfile.

The text was updated successfully, but these errors were encountered:

jotamartos commented Oct 31, 2019

You can also have an example here:

However, you should have received a similar error message to this one

We will review the code in our solution to know if there is something we can improve.

javsalgar commented Oct 31, 2019 •

We are going to release a new version of the container with several improvements. I’ll let you know the exact version. Could you confirm that the error still appears with this new container?

ashish-kumar-sw commented Oct 31, 2019 •

@javsalgar I will confirm with the new version, kindly share that.

juan131 commented Nov 1, 2019

but I guess this is optional and replication must succeed without these two parameters

As you can find in the link you shared:

MONGODB_REPLICA_SET_KEY: MongoDB replica set key. Length should be greater than 5 characters and should not contain any special characters. Required for all nodes. No default.

That environment variable is required for all nodes, it’s not optional.

ashish-kumar-sw commented Nov 1, 2019

@juan131 Actually the thing is, initially I followed this only :

So, MONGODB_REPLICA_SET_KEY variable should also be mentioned over there too!

juan131 commented Nov 1, 2019

You’re totally right. The README.md is wrong.

I just created a PR to update it. Please find it in the link below:

Thanks so much for reporting it!

ashish-kumar-sw commented Nov 2, 2019

Replication is still not working, It itself get detached after some time!!

juan131 commented Nov 4, 2019 •

Could you please share the containers logs? I’m unable to reproduce the issue.
Could you also please share the docker-compose.yaml you’re using?

ashish-kumar-sw commented Nov 4, 2019 •

Replication with single secondary is working whereas, for 2 secondary, it is not working.

juan131 commented Nov 4, 2019

I’m afraid you can’t scale your solution using the command below:

Please note that you’re setting the same environment variables for both secondary nodes. The environment variable MONGODB_ADVERTISED_HOSTNAME should be different on each secondary node.

We addressed this issue in the MongoDB helm chart, by automatically calculate the value to set based on the MongoDB pod name. See:

Источник

Nightscout crash: «MongoDB connection failed! Double check the MONGODB_URI setting in Heroku» #6775

Comments

philipgo commented Jan 20, 2021 •

Describe the bug
Every day or so my Nightscout crashes with the error message «MongoDB connection failed! Double check the MONGODB_URI setting in Heroku.»

The problem appears to be with Nightscout (or AndroidAPS??), I do not need to restart the MongoDB instance and other Nightscout instances continue to work with the same MONGODB_URI without any issues. However I do need to manually restart the Nightscout instance.

Expected behavior
Nightscout should not crash or if it does it should recover automatically.

Screenshots

Your setup information
MongoDB self hosted on a private server, Nightscout Docker (latest dev, but same issue on master) hosted on a different private server. My uploader is AndroidAPS 2.8.1.1

Logs

The text was updated successfully, but these errors were encountered:

sulkaharo commented Jan 20, 2021

Right — would it be possible for you to deploy this branch, so we’ll see what the error is. Looks like you’re hitting a previously unreported bug and sadly the current build doesn’t log the error that’s happening. #6777

sulkaharo commented Jan 20, 2021

philipgo commented Jan 20, 2021

I have deployed the websocket_dedupe_error branch and will wait for it to crash again and get back to you. Thank you for looking into this!

philipgo commented Jan 21, 2021

Here are the logs of a crash running your websocket_dedupe_error branch:
(The MongoDB logs show nothing exceptional)

lukebrogan commented Jan 21, 2021

I have just deployed the latest and got the same error straight away.

sulkaharo commented Jan 21, 2021

Dammit, @philipgo can you update to latest in the branch, there were two additional error spots like this, which now also capture the error. Btw how do you host the site? Based on the URL this is your own setup? Which Mongo version do you have? @lukebrogan Same to you — how are you hosting the site?

lukebrogan commented Jan 21, 2021

Hello!
I am deploying to Heroku 20 stack.
URL is https://cgm-luke.herokuapp.com/
Let me know if you need anything else.
Many thanks.

philipgo commented Jan 21, 2021

@sulkaharo Thank you, Sulka, already deployed.
My MongoDB version is v4.2.11. MongoDB is self hosted on a private server, Nightscout Docker hosted on a different private server behind an nginx reverse proxy. My uploader is AndroidAPS 2.8.1.1. I have never found anything in the MongoDB logs which could point to the cause.

@lukebrogan Your error may not be the same as mine. If your site never works: are you sure your MongoDB_URI is correct? My site works fine for hours or sometimes days, then it crashes.

lukebrogan commented Jan 21, 2021

Yeah you are right — it was an error in the MongoDB_URI string, all working for me now рџ‘Ќ

philipgo commented Jan 23, 2021 •

Here are the logs of another crash running the latest websocket_dedupe_error branch.

Some googling showed others are seeing similar errors in connection with useUnifiedTopology: true which was changed here recently.

sulkaharo commented Jan 25, 2021

@philipgo Given the logged error is simply that the connection has failed, I’m assuming this has to be something in your Mongo setup, as this hasn’t been reported by others. Not the Mongo Driver in Nightscout has been configured to auto-reconnect and this seems to be also fail in this case. FWIW I have a similar setup in Digital Ocean and have never had the Mongo connection fail in this manner. Wonder if there’s a Mongo forum somewhere that could help you?

philipgo commented Jan 28, 2021

I am still experimenting with different setups.

a Nightscout version without

Refactor mongo-storage.js В #6589 worked fine
a current dev Nightscout version removing both timeouts at

My MongoDB instance is super fast, so I would have no idea where timeouts might come from. However, is there a reason setting them to much shorter values than their defaults? Just removing the two lines will let them default to socketTimeoutMS = 360000 and connectTimeoutMS=10000.

One note: One of your changes in https://github.com/nightscout/cgm-remote-monitor/pull/6777/files causes the MONGODB_URI string to be displayed in full in the html error message on the web, including user name and password.

sulkaharo commented Jan 28, 2021

Right, increasing the timeouts makes sense. Note the connection time can be different from the query performance and if what you’re seeing is caused by a connection or socket timing out, that indicates there’s something odd either in the networking between the servers or the Mongo server is misbehaving and sleeping, or some other issue that slows down the handshake.

Источник

When Use Exposing IP with load balancing, Mongo will have a lot of logs #141

Comments

x-falcon commented Apr 26, 2019

04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected
04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected
04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected
04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected

The text was updated successfully, but these errors were encountered:

tompizmor commented Apr 29, 2019

@x-falcon What do you mean by Use Exposing IP with load balancing ? Set the service.type in values.yml to LoadBalancer or something else?

I installed the chart with the following command but I cannot see those entries in the log:

If you have a custom values.yml file, it would be nice if you share with us.

lookforstar commented May 20, 2019

04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected
04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected
04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected
04-26T16:23:21.656+0000 W NETWORK [listener] Error accepting new connection SocketException: remote_endpoint: Transport endpoint is not connected

I have the same problem. Have u sloved it? Could u give me some suggestions?

tompizmor commented May 20, 2019

@x-falcon you closed this issue. Do you know what was happening?

und3rs commented Oct 10, 2019 •

I have the same problem, too.

What should I do??

The way that I installed mongodb on k8s by helm chart is like this.

helm install -f ./values.yaml —name mongodb-logger stable/mongodb

tompizmor commented Oct 15, 2019

@und3rs Did you modify any default value in your values.yaml file? Which version of the MongoDB chart are you deploying?
I am not able to reproduce the issue with the latest version and default values.

und3rs commented Oct 15, 2019 •

Yes, I modified some settings about mongo version, security and so on.
That I know is that creating «docker service» as Loadbalance cause that issue in K8S.
I’m not sure the k8s some health check process make this issue.

tompizmor commented Oct 17, 2019

I am still unable to reproduce even using your values.yaml file.

Do you get that error since the very beginning after deploying the chart? Or you need to wait some time?

That I know is that creating «docker service» as Loadbalance cause that issue in K8S.

What do you mean? In your values.yaml the service type is ClusterIP

und3rs commented Oct 17, 2019

After deploying mongo with that valuse.yaml, I created another service as Loadbalace for to monitor.(assigned Public IP)
Because I need to access the mongodb directly on public network, too.

I think that service(loadbalance type) cause the errors.
If I remove the service, error does not appear.
But I re-create the seevice, errors appears again.

I’m using K8S of Alibaba Cloud.

und3rs commented Oct 17, 2019

So, in other words, when I have two services(clusterIP, Loadbalance) the errors occured.
If I remove the loadbalancer sevice, the errors dose not appear any more.

tompizmor commented Oct 22, 2019

@und3rs I have created the same load balancer service and check that I can access MongoDB using the external IP so it is properly configured. However, I am still unable to see those error messages in the MongoDB pod log.

Would it be possible for you to try to reproduce this issue on a different Kubernetes cluster? I am afraid I don’t have access to any Alibaba Cloud managed kubernetes.

daorren commented Nov 15, 2019

Closing LoadBalancer’s HealthCheck solves the problem

Footer

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник