Is there a way to reset the journal file. Will it have any implications ?
Right now i have a journal file of 2GB which is occupying lot of space in ec2.
You should stop the mongodb first:
service mongodb stop
rm -rf /var/lib/mongodb/journal
service mongodb start
Additional hint: you could limit the journal to 128MB by adding smallfiles=true to the config file /etc/mongodb.conf.
Solution taken from here and tested on Ubuntu 16.04.
No need to restart mongod service - this is not good solution sometime.
There is more simple solution if you just want to cleanup the single log file:
echo '' > /var/lib/mongodb/journal.log
Related
I am new to MongoDB. I am trying to install MongoDb 3.0 on Ubuntu 13.0 LTS, which is a VM on Windows 7 Host. I have installed MongoDB successfully (packages etc.), but when I execute the command sudo service mongod start, I get the following error in the "/var/log/mongodb/mongod.log" log file. Can anyone help me understanding this error. There is nothing on internet related to this.
2015-04-23T00:12:00.876-0400 I CONTROL ***** SERVER RESTARTED *****
2015-04-23T00:12:00.931-0400 E NETWORK [initandlisten] Failed to unlink socket file /tmp/mongodb-27017.sock errno:1 Operation not permitted
2015-04-23T00:12:00.931-0400 I - [initandlisten] Fatal Assertion 28578
2015-04-23T00:12:00.931-0400 I - [initandlisten]
I have fixed this issue myself, by deleting the mongodb-27017.sock file . I ran the service after deleting this file, which worked fine. However, I am still not sure the root cause of the issue. The output of the command ls - lat /tmp/mongodb-27017.sock is now
srwx------ 1 mongodb nogroup 0 Apr 23 06:24 /tmp/mongodb-27017.sock
Alternative to the answer provided by KurioZ7, you can simply set the permissions of the .sock file to the current user:
sudo chown `whoami` /tmp/mongodb-27017.sock
This does the trick for me if I want to run mongod without sudo. If I delete the file like in KurioZ7s answer, I will simply get the same error the next time I restart my machine.
This issue occurs when you use the command
mongod
Before using the command
sudo service mongod start
To fix the issue, either:
Set appropriate permissions on the file:
/tmp/mongodb-27017.sock
OR
Remove the file
/tmp/mongodb-27017.sock
Run
sudo service mongod start && mongod
The most likely cause for this was that the mongod process was at some point started by the root user. The socket file (/tmp/mongodb-27017.sock) was therefore owned by the root user. The mongod process usually runs under its own dedicated user, and that user did not have the permissions to delete that file.
The solution, as you already found out, was to delete it. Then mongodb was able to recreate it with the correct permissions. This should persist after reboot, as long as mongodb is started using the init scripts, or under the correct user account.
$ sudo mongod
it solve problem for me
Change the ownership mongodb-27017.sock file in /tmp directory and start the mongod again.
cd /tmp
sudo chown mongodb:mongodb mongodb-27017.sock
sudo systemctl start mongod
For UNIX-based operating systems, as an alternative to the answer provided by Bastronaut, you could also specify the .sock file to be saved to a folder over which mongod has full user rights (corresponding to the way you are running mongod), that way mongod will also be able to remove the .sock file upon shutdown. The default folder to which the .sock file is saved is '/tmp'. To specify another folder, use a custom mongodb configuration file, for instance 'mongodb.conf', and add the following to it:
net:
unixDomainSocket:
pathPrefix: "anotherFolder"
After which you can run mongod with the command:
$ mongod --config /path/to/mongodb.conf
You can read the documentation on: https://docs.mongodb.org/manual/reference/configuration-options/#net.unixDomainSocket.pathPrefix
Manually restarting mongod service after restart fixed the problem.
Long-term solution was to add static host name, instead of ip address 'net' part of mongod.conf file (I suspect the problem is that ip address is not yet given to server, when mongod servis starts).
If you are having this problem using docker, refer to this question:
MongoDB docker container “Failed to unlink socket file”
I installed mongodb a few days ago on my ubuntu machine and I was using it without any problems. Today I had to restart my PC. After that, mongo simply wont start. It says:
Wed Sep 12 21:41:21 [initandlisten] exception in initAndListen: 10296 dbpath (/data/db/) does not exist, terminating
It was working fine just a few hours ago and now it's all screwed up on reboot. I had a lot of important data stored there and I really hope it's not all lost! I need to find that data and run mongodb on that data again. I use pymongo to interract with mongodb.
I just saw the config file and it's storing the data in /var/lib/mongod as the dpath. Now how do I start mongodb specifying this dpath?
You can start mongodb with the following switch.
mongod --dbpath /path/to/mongodb/data
Or edit the config file.
/etc/mongod.conf
Change dbpath to your data directory.
dbpath = /path/to/mongodb/data
There's a lot more you can add and change in the config file go here for more details.
Use this command to create your directory tree.
mkdir -p data/{db}
Use the following command to start mongod:
sudo service mongodb start
This will pass your system configuration file as an argument to mongod, which (as you saw) will cause it to use the correct path.
you need a path to store your database. by default it is /data/db/. if it does not exist you have to create it first
One of the reason for this error can be the fact that you are starting the mongodb with user as yourself. If you execute the command with sudo, the mongodb should start without error:
sudo mongod --dbpath /path/to/mongodb/data
One can find the path to mongodb data in file such as /etc/mongod.conf
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.
UPDATE: this was fixed after Meteor v0.4 (2012). For historical purposes:
Excerpt from du:
2890768 ./Code/Meteor/QuarterTo/.meteor/local/db/journal
2890772 ./Code/Meteor/QuarterTo/.meteor/local/db
2890776 ./Code/Meteor/QuarterTo/.meteor/local
2890788 ./Code/Meteor/QuarterTo/.meteor
2890804 ./Code/Meteor/QuarterTo
I merely ask because it was in my Dropbox and pushed me over my limit.
When meteor run is executed, it starts mongodb with default mongo settings, so it creates (massive) prealloc files in .meteor/local/db/journal.
There is no obvious way to disable this behavior. What I have done as a workaround is change the file app/lib/mongo_runner.js and add a --nojournal parameter that gets passed to mongodb at startup.
I created an issue for this: https://github.com/meteor/meteor/issues/15
Maybe you can use smallfiles=true parameter for mongoDB? It will create smallest prealloc files
You can turn off preallocation by passing the --noprealloc arg to mongod. The downside is that there will be pauses each time a new storage file needs to be allocated. Depending on the filesystem you are using (e.g., ext3 vs. ext4), this could result in noticeable latency for a user.
The commands that work for me are:
stop mongodb instance if it is running
sudo service mongod stop
create new mongodb instance without requiring 3+GB preallocated space and use smallfiles.
mongod --noprealloc --smallfiles
If you are getting “ERROR: dbpath (/data/db) does not exist.” when running 2,
then run these commands before 2.
sudo mkdir -p /data/db/
sudo chown `id -u` /data/db
My server went down from an electrical failure and for a few horrifying seconds, I thought I'd lost all MongoDB data. I then realized that when the server restarted, mongo automatically restarted without the --dbpath option.
What I can't figure out is why, even though my mongodb.conf has the dbpath set to /var/lib/mongodb, mongo looked for the db files in /data/db on startup. Can anyone shed some light on this?
Thanks!
/data/db is the default path that mongod will look for data files in if it is started with no options. Does your startup script instruct mongod to load the correct config file? If not, that would explain this behavior.
When was the last time you updated Mongod on your system? and how did you update it?
Depending how you installed / updated Mongod it could happen that either the /etc/init.d/mongo script or the /etc/mongo.conf files could be overwritten.
Or somebody edited those files a long time ago, and this is the first time Mongo got restarted, and now it looks like there's suddenly a change.
I haven't seen either of those two things happen in a long time (but if you're using Gentoo, you would probably see this happen)
What OS do you use?
It's a good idea to keep backups of those files...
You should definitely ensure that your init script for Mongo includes the full pathname to the data directory. Here is a snippet of what we use in our production deployment:
ulimit -s unlimited
MONGO_USER=mongo
MONGO_HOME=/opt/mongo
MONGO_DATA=/san2/data
MONGO_LOGS=/home/mongo/logs
start() {
su $MONGO_USER -c "$MONGO_HOME/bin/mongod --master --fork --logpath $MONGO_LOGS/mongodb.log --logappend --dbpath $MONGO_DATA --maxConns 2400"
}
Check the startup options in /etc/default/mongodb most likely those will be set to the default path of /data/db instead of the one you selected when you started it up manually.