MongoDB not using /etc/mongodb.conf after I changed dbpath - mongodb

Ever since I changed the dbpath in /etc/mongodb.conf, MongoDB has not been starting automatically, nor using the new dbpath. Prior to the change, MongoDB would be running when the computer started and I was able to simply run the command mongo to get into the console or start my Ruby on Rails server with no issues.
After I made the modification (in order to switch to a new drive with more space), the only way I can get everything to work is by manually running the command mongod --config /etc/mongodb.conf. If I don't run that, it doesn't seem like the service is running and running without the --config option give me the following error: ERROR: dbpath (/data/db/) does not exist. even though the config file says nothing about data/db.
Some other notes:
In addition to changing /etc/mongodb.conf, I moved all files out of /var/lib/mongodb and into /home/nick/appdev/mongodb.
I changed the owner and group from root to nick. Tried changing it back, but it didn't seem to fix anything.
I'm running Ubuntu 12.10 Beta 1 and Mongo 2.2.0 with Ruby on Rails 3.2.8

A late follow up on the above question...
I had a similar issue after moving the db to an ebs on ec2.
It turns out that just running mongod still directs the dbpath to /data/db/ (which exists).
The /etc/mongodb.conf is completely ignored unless specifically directed to.
I manage to work around this by using the directive --config or just the --dbpath(both work)
But was left wondering where does mongod takes it defaults from...?!
I was unable to locate and override these defaults anywhere.
Anyone ?
Note:
I am really annoyed by this behaviour of mongod...This is just bad design,and bad documentation.

It turns out that I needed to set the owner and group to mongodb. When I transferred the files to the new directory, I had set the owner and group to my user account nick and also tried root, neither of which worked.
To do so, here are the following commands:
sudo chown mongodb /home/nick/appdev/mongodb -R
sudo chgrp mongodb /home/nick/appdev/mongodb -R
To confirm that it worked, you can check the file permissions with:
ls -l /home/nick/appdev/mongodb

After checking all permission in the data, journal and log folders as suggested, my problem was solved by giving permission to a lock file in the /tmp folder
sudo chown mongod:mongod mongodb-27017.sock
I was running it as a AWS Amazon Linux instance. I figured that out by executing as the mongod user as below, and then, researching the error code. It might be useful for other troubleshooting.
sudo -S -u mongod mongod -f /etc/mongod.conf

MongoDB 1.6 is very old and the latest production version is 2.2, which contains a large amount of bug fixes and enhancements since 1.6.
Am I correct that you haven't installed 1.6 via a package manager such as yum or aptitude? I don't believe there are packages for 1.6 at present afaik. Therefore, mongod is behaving correctly as you have not started MongoDB with a control script.
Please see this link on configuration file options.

Related

IllegalOperation: Attempted to create a lock file on a read-only directory MongoDB in ubuntu 20.04

I have just installed mongodb on my remote ubuntu server for using it with an angular and nodejs project. I created a user using the db.createUser command along with password and roles in the mongo shell.
Then when i try to start the mongodb instance with access control using the command:
mongod --auth --port 27017 --dbpath /var/lib/mongodb
its displaying the error:
IllegalOperation: Attempted to create a lock file on a read-only directory MongoDB
First of all, have you checked the permissions of the folder /var/lib/mongodb (ls -l /var/lib)?
The folder and its contents should be assigned to the mongod user. You could also check the ACL permissions (getfacl), if that's installed in your system.
If permissions seem correct, please continue reading to know how I solved the same error in a different environment.
This happened to me in CentOS 8 after a wrong reinstallation of MongoDB and the data folder /var/lib/mongo had to be created manually. In my case, the problem was that the security context of SELinux (https://www.redhat.com/en/topics/linux/what-is-selinux) had to be updated to give mongod access the folder.
The command below solved my problem (note the path to the data folder in my configuration is slightly different, just update it for your case):
chcon -Rv --type=mongod_var_lib_t /var/lib/mongo
It basically tells SELinux that the context used by MongoDB to access the files should be associated with the target folder.
You can have more information about chcon here: https://www.man7.org/linux/man-pages/man1/chcon.1.html

Running an instance of mongod from terminal ends with "[initandlisten] shutting down with code:100"

I've been searching for an answer for a week now and haven't found out how to keep this from happening. I currently have mongo stored from my root directory into a file with path /data/db. The contents of this directory after typing ls...
Contents of /data/db
After I run the command mongod I see this...
After running mongod
I've installed mongodb with homebrew and have followed the installation rules over and over after installing and uninstalling thinking I made a mistake. I'm stuck and am new to mongodb altogether. I've noticed that Homebrew is installed in /usr/local/ and I believe mongo is stored in /data/db/.
I think there is some permission issue. Try changing the group and owner of the directory and the directory where socket file is being created through the command
sudo chown mongo User:mongo User data/socket directory

Installed docker and ran a container with mongodb, now brew's mongodb isn't working

I recently installed docker and ran a container with mongodb, now my local brew's mongodb isn't working.
I am using a mac and originally installed mongodb using homebrew. brew services list now shows the mongodb service as 'running' but in yellow (apparently this means unknown), and I cannot connect using mongochef. This began happening after only once stopping the service brew service stop mongodb, as it was preventing me from using docker with this project: https://meanjs.org/. I stopped the service because there was a conflict for the mongodb port. Now even after destroying all the docker containers, I can't get mongodb working on my machine. I have tried reinstalling mongodb using brew, and stopping and starting the service.
I have also tried deleting the file in /tmp as here:
MongoDB Failing to Start - ***aborting after fassert() failure
Any suggestions about where to look and what to do?
So this turned out to be one of those really annoying problems that comes up when you have a lot of other stuff to do. I am still not completely sure if it was one issue or multiple issues. If I was to try and fix it again though, this is the order I would go in:
I removed mongo completely and reinstalled (this finally fixed the mongodb service's status from being shown in yellow instead of in green), as here: https://gist.github.com/katychuang/10439243:
# checks to see if running
launchctl list | grep mongo
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.mongodb.plist
launchctl remove homebrew.mxcl.mongodb
pkill -f mongod
rm -f ~/Library/LaunchAgents/homebrew.mxcl.mongodb.plist
brew uninstall mongodb
# double check existence
ls -al /usr/local/bin/mong*
ls -al ~/Library/LaunchAgents
# this was mentioned in the comments
rm -R /usr/local/var/mongodb
However, I think my data was corrupted too. Unfortunately mongod --repair (mongodb error: how do I make sure that your journal directory is mounted) was saying it couldn't repair the data without running with --journaled but that didn't work either. So I deleted my databases in /data/db I didn't need them anyway because I have backups and just restored them easily.
Hope that can help anyone having similar issues.
Sidenote:
The mongod command on the command line gave some helpful output in tracking this down.
Also vim ~/Library/LaunchAgents/homebrew.mxcl.mongodb.plist allowed me to see which command was being run:
<string>/usr/local/opt/mongodb/bin/mongod</string>
<string>--config</string>
<string>/usr/local/etc/mongod.conf</string>
This showed me that /usr/local/etc/mongod.conf was being used, and realising that whilst running /usr/local/opt/mongodb/bin/mongod was working, running:
/usr/local/opt/mongodb/bin/mongod --config /usr/local/etc/mongod.conf was not working, helped me narrow the problem down

mongod command "corrupting" MongoDb installation?

I am using Ubuntu 14.04 LTS and I have installed MongoDB 3.2.1. I had various problems with it that I fixed by either finding help from the internet (thanks Google) or by uninstalling and re-installing MongoDb.
One persistent problem that I cannot fix, unless I re-install, is by running mongod on the terminal. Currently my mongodb installation is working properly. With sudo service mongod start I start mongodb (I commented out start on xxxx line at /etc/init/mongod.conf so it doesn't auto start.) and with sudo service mongod stop I can stop it normally atm. And it correctly uses /var/lib/mongodb path for saving my collections.
If however after I stop mongodb with sudo service mongod stop I hit, on the terminal, mongod then mongodb breaks. I have gotten all kinds of errors like
Unusable mongod.lock. I have gotten around it, in a previous install, by doing sudo mongod but that was not a proper solution.
/data/db folder not found !!. Why look for it in the first place? The /etc/mongod.conf specifies the dbpath /var/lib/mongodb which is also the default when mongodb gets installed !!?? I have gotten around it as well with the mongod --dbpath /var/lib/mongodb option.
I think there was one more error that I don't remember but I also fixed/gotten_around it by finding solutions online.
I know that by re-installing and by never running mongod I can - for now? - not face those problems again (which looks a much better solution that the "workarounds" I did whenever those problems arose. I am wondering however what it is that is going wrong when I type mongod instead of sudo service mongod start ?!
In case somebody tries to replicate the problem know that I ve done only two modifications on my system after installing:
Commenting out the start on xxxx line at /etc/init/mongod.conf
Disabling transparent hugepages as described on the answer here.
I don't think anyone of those should interfere with my installation.
Can anyone help me understand what is going on? Aren't those commands supposed to do the same thing??
Thanks for your help.
Ok, I will try to answer.
First, unless you know what you are doing, you should not start mongod manually.
In general (a bit simplified), calling [sudo] service mongod start, you instruct the system to read the according file in /etc/init and start the executable according to the configuration described in said file.
When you started mongod by hand, however, you actually called the mongod binary, the server software itself – while the name is the same as the service, the two commands have few things in common. The binary does not use the /etc/mongod.conf by default, falling back to its default values for the various settings. Actually, you can see that the config file is explicitly defined in the init script. This is why mongod tried to find /data/db.
You can find said binary by issuing
which mongod
Regarding the lock file: When mongod is started by the system, user root actually assumes the effective user id of mongod (or mongodb I don't know for Ubuntu of the top of my head). When you tried to start it from your user id, you do not have the privileges to overwrite the lock file. When you used sudo mongod afterwards, you assumed the effective user id of root which on the other hand is allowed to overwrite said file. However, mongod will the run as root which is a security no-no.
An init script defines which environment to use, which user to run under and a lot of other stuff. Unless you really know what you are doing, you should not even fiddle with them, much less skip it.
And now, with the finger up
sudo is not the UNIX way of saying "I mean it!"
It has security implications, and you should be very aware of those implications before using it – aka read the man pages of every command you issue before you use it until you have at least a fact based idea of what the command is doing.
And again: unless you really know (as opposed to assume) what you are doing, do not fiddle with the system configuration.

Moved Mongo Database to Different Drive: Unable to acquire lock for lockfilepath

I am in the process of moving my mongo data to a different drive. All of the data I want to move is stored in /data/db and I am moving it to a NAS (Network attached storage).
First step:
mongodump -d mydb -c mycollection -o nas/mongo-temp
This created a file tree in mongo-temp/ like so:
dump
`-- mydb
`-- mycollection.bson
1 directory, 1 file
I then stopped the mongod service and created a new /data/db directory:
/etc/init.d/mongod stop
mkdir mongo-temp/data/db
...and changed the dbpath line in /etc/mongodb.conf
dbpath=.../mongo-temp/data/db
I successfully restarted the mongo server using /etc/init.d/mongod start.
When I try to connect:
mongo
MongoDB shell version: 1.6.4
Thu May 3 09:53:23 *** warning: spider monkey build without utf8 support. consider rebuilding with utf8 support
connecting to: test
Thu May 3 09:53:24 Error: couldn't connect to server 127.0.0.1 (anon):1154
exception: connect failed
I've tried to start mongod with the command mongod --dbpath .../mongo-temp/data/db but I get an error that says:
Thu May 3 09:57:26 exception in initAndListen std::exception: Unable to acquire lock for lockfilepath: /home/dlpstats/nas-mnt/mongo-temp/data/db/mongod.lock
Removing the lockfile doesn't help. If I run the mongod command without --dbpath, the server starts fine and I am able to make queries on my old database.
First, you mentioned that you used mongodump to populate the new drive - was this just a method of backing things up or did you intend that to be the new database files? That is not how it works - mongodump output is not the same as a database file - it needs to be re-imported with mongoresore in fact. If you do a straight data file copy then the transfer will be seamless.
Then, as well as the permissions suggested by Wes in his answer, a few more things to check:
That you have shut down the old server successfully and completely - it's possible it's mis-reported error and you are getting it because it is trying to grab a port that is already open
You are using version 1.6.4 according to the mongo shell output, my guess is that you installed from the Ubuntu repo for 11.04 or similar, that is not a good option - 1.6 is very old at this point. Use the 10gen repos (http://www.mongodb.org/display/DOCS/Ubuntu+and+Debian+packages) or download the binaries and get a more recent version
Last but not least, when you start the mongod manually, make sure all the arguments are the same, like the port. When you connect via the mongo shell, specify the port you started the mongod on - don't rely on defaults when running into issues like this, be explicit.
I faced this problem and issuing following command solved my problem:
rm /var/lib/mongodb/mongod.lock
And then restart the mongod.
But I'm not sure is it a good solution or not.
Check the permissions for the directory and parent directories of mongo-temp. Presumably it's running as the mongodb user?
You need execute permissions on the directory (and parent directories) in order to create files there. Execute permissions on a directory allow you to list the files there, which is needed to be able to open the file for writing.