Ubuntu MongoDB not starting as a service, nothing in the log

I am running MongoDB 2.2 on Ubuntu, and if I run:

sudo mongod 

I get an error that cannot find / data / db, and not where the database is located. In mongod.conf, the database path is set as Ubuntu 10gen by default /var/lib/mongodb where db is located. mongod does not seem to find the conf file. So when I run:

 sudo mongod -f /etc/mongodb.conf 

The server starts normally and the output is written to the log file: /var/log/mongodb/mongodb.log . Everyone is happy. I can switch to another shell, enter the mongo shell, look at the databases and execute the queries.

So, I cancel this and try to start the service:

 > sudo status mongodb mongodb stop/waiting > sudo start mongodb mongodb start/running, process 10468 

It looks good, but the mongo server did not start. Running another:

 > sudo status mongodb mongodb stop/waiting > mongo MongoDB shell version: 2.2.0 connecting to: test Sat Sep 1 19:07:43 Error: couldn't connect to server 127.0.0.1:27017 src/mongo/shell/mongo.js:91 exception: connect failed 

"test" is not a valid database, and nothing is displayed in the log file.

I do not understand what might be wrong. I checked the upstart scripts and they seem beautiful. /etc/init/mongodb.conf works:

 mongodb --exec /usr/bin/mongod -- --config /etc/mongodb.conf 
+48
mongodb ubuntu service
Sep 01 '12 at 23:11
source share
11 answers

OK, it all comes down to permissions, but let it take you step by step. When you run sudo mongod , it does not load the configuration file at all, it literally starts with the default compiled ones - port 27017 , the database path / data / db, etc. - that’s why you got a message about the lack of the ability to find this folder. "Ubuntu default" is used only when you specify it in the configuration file (if you start using the utility command, this is done for you behind the scenes).

Then you run it like this:

 sudo mongod -f /etc/mongodb.conf 

If there were no problems before, then it will be - you started the process, with your usual configuration (pointing to your usual dbpath and log) as the root user. This means that in this regular MongoDB folder there will now be several files with the user: group root:root group.

This will lead to errors when trying to start it as a regular service again, because the mongodb user (which the service will try to execute as) will not get permission to access these root:root files, and most importantly, it probably won’t be able to write to log file to provide you any information.

Therefore, to run it as a regular service, we need to fix these permissions. First, make sure MongoDB is not currently running as root, and then:

 cd /var/log/mongodb sudo chown -R mongodb:mongodb . cd /var/lib/mongodb sudo chown -R mongodb:mongodb . 

This should be fixed (assuming the user: mongodb:mongodb group mongodb:mongodb ), although it is probably best to check with ls -al or similar to be sure. Once this is done, you can start the service again.

+102
Sep 02
source share

First confirm that the mongodb user / group has permission to write to the data directory and log :

$ sudo chown -R mongodb: mongodb / var / lib / mongodb /.

$ sudo chown -R mongodb: mongodb / var / log / mongodb.log

Launch MongoDB as a Daemon (background process) using the following command:

$ mongod --fork --dbpath / var / lib / mongodb / - smallfiles --logpath /var/log/mongodb.log --logappend

In Shut Down MongoDB, enter the Mongo CLI, access the administrator, and issue the shutdown command:

$. / mongo

use admin

db.shutdownServer ()

Link: http://www.mongodb.org/display/DOCS/Starting+and+Stopping+Mongo

+36
Oct 25
source share

I had the same problem too. So I went to cd / var / lib / mongodb / and deleted the mongod.lock file. Then it worked for me.

+9
Dec 22
source share

After checking all the permissions in the data, log and log folders suggested by @nelsonic, my problem was resolved by allowing the file to be locked in the / tmp folder

 sudo chown mongod:mongod mongodb-27017.sock 

I ran it as an instance of AWS Amazon Linux. I figured this out by executing mongod as a user, as shown below, and then examining the error code. This may be useful for other troubleshooting methods.

 sudo -S -u mongod mongod -f /etc/mongod.conf 
+3
Jan 13 '17 at 14:59
source share

Nothing worked for me, then I found that this is a problem with permissions in the /tmp :

 sudo chmod 1777 /tmp sudo chown root:root /tmp 
+2
Jan 06 '16 at 12:03
source share

None of the above answers worked for me. I finally figured this out by debugging the init script with

sudo bash -x / etc / init.d / mongodb start

And, seeing that it skips the wrong configuration path to mongod. I just changed the line in /etc/init.d/mongodb from "CONF = / etc / mongodb.conf" to "CONF = / etc / mongod.conf". Version 2 uses the first, and the installation of version 3 is added /etc/mongod.conf with the new format, but apparently did not update the init script.

UPDATE: I now have a much more complicated problem when the init script works, but only if I run it using "sudo bash -x / etc / init.d / mongodb start" and not using "sudo service mongodb start". The same goes for the stop.

+1
Aug 29 '16 at 5:35
source share

Just try this command:

 sudo chown mongodb /tmp/mongodb-27017.sock 
+1
Jun 14. '17 at 13:20
source share

My mongodb was launched when launched from the command line as a mongod user, but not as a service with User = mongod. After an hour of checking permissions, defining a service, sockets ... it was SElinux!

In / etc / selinux / config, I switched from forced to permissive and rebooted. Now everything is all right.

+1
Dec 03 '18 at 15:34
source share

After none of the above answers worked for me, deleting my log file led to the revival of Mongo.

0
Oct. 31 '16 at 4:03
source share

Nowadays, this error can occur if you updated mongod and you are running and the old database. Mongod will use the wiredTiger engine by default and you will have a mmapv1 database

edit the engine setting in the /etc/mongod.conf file

 # engine: wiredTiger engine: mmapv1 

Caution - YAML is space-sensitive

journalctl / systemd will not see this problem. Check the mongod log in /var/log/mongodb/mongod.log

I assume you can convert the database with something like the steps described here

https://docs.mongodb.com/manual/tutorial/change-standalone-wiredtiger/

0
May 25 '17 at 18:59
source share

also check the hard disk space, because if / var / log is full, the service cannot add logs.

0
May 14 '19 at 9:43
source share



All Articles