I try to shutdown mongoD in order to make a backup. However when I send service mongod stop it totally failed Stopping mongod:[FAILED]
I took a look on mongodb logs and there is nothing about shutdown...
I've got important data on this DB and i don't want to kill anything, so as i'm a beginner in mongoDB, I prefer to ask here what to do before destroy everything.
I was thinking about kill the process of MongoD, make my backup with mongodump and restart MongoD, but i'm not sure that it will work.
Thanks for helping.
For my MongoDB 3.0 install, the problem with stopping was caused by a comment field in the /etc/mongod.conf file:
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile
This caused a problem with the awk command in /etc/init.d/mongod that defines the PIDFILEPATH since the comment text became part of the path, which then meant the mongo_killproc would not work.
I fixed this by editing the mongod.conf to move the comment to a separate line and now all is good (I did not have to change the quotes around $PIDFILEPATH either)
I had the same issue. In my case it worked after editing the mongod init script. You need to remove the quotes from $PIDFILE in the stop function definition. You might need to kill the mongo process first in order for it to work.
Hope this helps.
In my case it was "PIDFILEPATH" in the stop function and I removed the quotes
I think killing processes of mongodb would definitely work
sudo killall -15 mongod
Related
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.
I have MongoDB installed and working on my computer (Using Ubuntu 14.04 for the operating system).
The problem is, every time I go to start it, it takes me messing with it for a few minutes before I can get it to successfully start. Usually, some combination of running
mongod --dbpath ~/data/db
or
rm -rf ~/data/db/mongod.lock
or finding and killing the running but broken isntance with
ps wuax | grep mongo
kill <pid>
is what it takes to get it working again.
What would cause this? Every time I google this issue, it's all the same answers to just get it fixed, but not permanently make it start and stop correctly, just to fix it when it happens incorrectly.
i had the same issue of having to specifying --dbpath every time so i just created the two folders /data/db in my root directory and now had just to type mongod to start MongoDB. Note that this requires superuser privileges. Hope it helps
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 am totally a beginner with mac , I get this error while trying to open the server using mongod
10309 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminatin
The error usually indicates that the lock file is still present from a previous run. That means that the mongod process is stil running, check:
ps auxwww | grep mongod
If it is not listed, then remove the lock file and start mongod again. If it is listed and unresponsive you may have to kill the process (assuming you cannot connect). Try a regular kill before a kill -9 etc.
If the process is not there, or you kill it successfully, remove the lock file and restart mongod - if you had journaling enabled everything should be fine. If not, you may need the repair operation suggested by Sean.
Run sudo mongodbecause you need to have admin access. From there, you just need to type in a password.
Do you have journalling enabled? If not, and your mongod instance crashed, then you may need to perform a recovery. In this case, what you should do is
start mongod with the repair switch: mongod --repair. It will run, and then terminate having deleted the lock file.
start mongod again normally.
Once you do this, I highly recommend that you enable journalling by using the --journal command line switch when you start mongod.
If I remember way back when, you need to sudo mkdir /data: I believe that MongoDB will assume that the base directory that it needs exists and won't create it on its own.
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.