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
Related
I have mongo setup with homebrew.
$ brew services start mongodb-community
$ mongosh
I can see my DBs in mongo compass.
I want to run this DB but in a replica set. But I can't figure out how.
I tried using the run-rs package. But it didn't work.
I installed the package.
$ npm install run-rs -g
Then I ran run-rs, but it failed:
$ run-rs --mongod
Purging database...
Running 'mongod' [ 27017, 27018, 27019 ]
Starting replica set...
Error: failed to start mongod with options [
'--port=27017',
'--dbpath=/Users/projectpath/backend/data/27017',
'--bind_ip=localhost',
'--replSet=rs'
]
So then, I stopped MongoDB.
$ brew services stop mongodb-community
I ran run-rs again.
$ run-rs --mongod
Purging database...
Running 'mongod' [ 27017, 27018, 27019 ]
Starting replica set...
Started replica set on "mongodb://localhost:27017,localhost:27018,localhost:27019?replicaSet=rs"
Connected to oplog
(node:28395) [MONGODB DRIVER] DeprecationWarning: collection.find option [oplogReplay] is deprecated and will be removed in a later version.
(Use `node --trace-deprecation ...` to show where the warning was created)
But this created a data folder with many files in my project directory. I don't want a bunch of project files in my directory. Are these files expected? If so, where should these files go? How do I get them into the correct directory? How come it's not behaving like my other mongo setup?
Now all the DBs I had before in mongo compass are gone. I can get back to them if I kill all mongo processes
$ ps wuax | grep mongo
$ kill (pid number)
and run:
$ brew services start mongodb-community
But How can I get my regular mongo community to use a replica set? Why are my mongo DBs gone when I run run-rs? And why does run-rs put many files in my project directory?
Am I missing how this is supposed to work?
UPDATE
I tried to add the homebrew path.
$ run-rs 5.0.6 --dbpath '/opt/homebrew/var/mongodb'
The data folder isn't added to my project now. But my old DBs shown in the first image are not in Mongo Compass anymore. Now when I switch to brew services start mongodb-community all my dev databases seemed to be removed.
It seems that once you get run-rs to work it purges your DB data so it doesn't seem you can run a replica set with your old db data without saving it somewhere and copying it back. It also seems you have to turn your homebrew mongo off. I'm not really sure what I'm talking about but this is how I got it to work.
I set up run-rs and had to reseed my dev DB.
Here's how I set up the local replica set:
Turned off mongo-community:
$ brew services stop mongodb-community
Installed and ran run-rs using my data directory path ('/opt/homebrew/var/mongodb') and my mongo version (5.0.6). Mongo Compass gave me an error when I ran run-rs --mongod instead of run-rs 5.0.6 even though the version was 5.0.6 in both.
$ npm install run-rs -g
$ run-rs 5.0.6 --dbpath '/opt/homebrew/var/mongodb'
# if you don't want to purge the database add the flag --keep
Then I ran my seed file and populated a new db at the uri: mongodb://127.0.0.1:27017/wtdev-local?replicaSet=rs
Make sure to add replicaSet=rs to your URI.
NOTE
I kept having issues from running run-rs in the past incorrectly or some other instance of mongo, and then trying to run mongo again while the old one was still running. My terminal would tell me mongo was already running on port 27017. Whenever this happened, I found the PID and killed any mongo PID's.
$ ps wuax | grep mongo
$ kill (pid number)
I have recently installed PostGIS on my Mac (El Capitan 10.11.4, Postgres is version 9.5.1) using Homebrew, and I am following these instructions - http://morphocode.com/how-to-install-postgis-on-mac-os-x/
When I try to start Postgres using
pg_ctl -D /usr/local/var/postgres start
I get the following error:
$ FATAL: lock file "postmaster.pid" already exists
HINT: Is another postmaster (PID 280) running in data directory "/usr/local/var/postgres"?
So I spent a few hours researching how to address this, but to no avail.
Notably, I tried to kill the PID as recommended in an answer on Superuser - https://superuser.com/questions/553045/fatal-lock-file-postmaster-pid-already-exists- (in the case above, I ran kill 208), but as soon as I tried to start Postgres again, I got the same error, albeit with a different PID number. I saw a few people recommended deleting the postmaster.pid file, but I feel like maybe I should save that as a last resort...
Admittedly part of the reason I'm not sure how to fix this is that I'm not really clear on what the postmaster even is - I'm just starting to learn about all of this.
Hopping into a Postgres database via the psql db_name command works just fine, for what it's worth.
Posting this in case it helps someone else:
I was having this same problem as the OP after a hard reboot when my laptop crashed. What helped me was running the following command to see what PID was associated with postmaster.pid:
cat /usr/local/var/postgres/postmaster.pid
The first number that appears will be the PID. Looking in Activity Monitor, I was able to see that Postgres was running, but without a PID number that matched the one shown.
Instead of the steps outlined in the answer referenced on Superuser, I restarted my laptop properly and then opened up Terminal and ran
brew services restart postgresql
This worked without having to remove postmaster.pid, which I saw a few other posts recommend. Sometimes it's the simple solutions that work.
I add here what worked for me, after a long time of searching:
Delete the postmaster.pid file:
rm /usr/local/var/postgres/postmaster.pid
Restart your postgres:
brew services restart postgresql
Hope this helps someone ...
Update 8/2022:
As Mike commented, for M1 Mac you would replace stage 1 with:
rm /opt/homebrew/var/postgresql/postmaster.pid
With M1 and specify Postgres Version # 14
rm -rf /opt/homebrew/var/postgresql#14/postmaster.pid
It often happens to me in OSx, when my system shutdown unexpectedly.
You can just remove the file postmaster.pid.
cd Library/Application Support/Postgres/var-{postgres-version}
and remove the postmaster.pid file
in case you use brew then your path should be something like:
/usr/local/var/postgres/postmaster.pid
restart the Postgres by using this command
pg_ctl -D /usr/local/var/postgres restart
Since you can connect to the database, you don't need to start the server again - it's already running.
pg_ctl is used to control the PostgreSQL server. Since your server is already started, your command:
pg_ctl -D /usr/local/var/postgres start
Returns an error, saying that there is a lock on postmaster.pid - which is true since there is already a server running under that PID.
There are two ways:
The most basic way - skip that step, your server is already running!
Executing a needless operation - stopping the server, and then starting it again.
You could stop your server doing :
pg_ctl -D /usr/local/var/postgres stop
So that you won't have the lock on postmaster anymore and you could use your command to start it again.
Postmaster is the main PostgreSQL process. You're trying to start PostgreSQL that's already running (and you're saying yourself you can connect to it). Just skip that step of your process.
When the system shutdown unexpectedly, my postgres crashs and i'm unable to connect to it.
What worked for me was:
1˚ Check postgres log:
tail -n 10000 /usr/local/var/log/postgres.log
2˚ Find the PID of postgress, should look like this:
FATAL: lock file "postmaster.pid" already exists
HINT: Is another postmaster (PID 707) running in data directory "/usr/local/var/postgres"?
3˚ Kill that process:
kill 707
4˚ Restart your postgres
brew services restart postgresql
After those steps i was able to connect to the database within my rails application.
If you got no important data to lose :
sudo killAll postgres
brew services restart postgresql
AGAIN : You could get data corrupted by doing this !
do it at your own risk !
I am using mac and these step work for me:-
step1: cd Library/Application\ Support/Postgres
(most commonly your Postgres installation will be located here)
step2: cd var-13
(if you are using version 12 then use cd var-12. Hope got the point)
step3: ls
(As you can see among the files you find the postmaster.pid, perfect.)
step4: rm postmaster.pid
When you have removed the stale postmaster.pid file you can restart PostgreSQL and everything should work as normal.
My OSX laptop had shutdown unexpectedly, and I was getting a stale postmaster.pid error in the PostgresApp. Shutting down my laptop and turning it back on again solved the problem.
After running the following commands
rm /usr/local/var/postgres/postmaster.pid
brew services restart postgresql
The error lock file "postmaster.pid" already exists comes up again.
When we run launchctl list | grep postgres
28618 0 homebrew.mxcl.postgresql
The existing file "postmaster.pid" was created by this daemon process hosted by launchctl.
We try to stop the homebrew.mxcl.postgresql through
sudo launchctl stop homebrew.mxcl.postgresql
launchctl disable homebrew.mxcl.postgresql
Unfortunately, none of them could stop the homebrew.mxcl.postgresql.
The reason is Disable and enable an agent using (persists between boots)
https://apple.stackexchange.com/questions/105892/disable-services-in-osx-services-msc
launchctl enable <name> or launchctl disable <name>
Two ways to solve it when the error lock file "postmaster.pid" already exists comes up again
In order to stop an agent immediately through
launchctl kill homebrew.mxcl.postgresql
Restart your desktop and run brew services start postgresql#14. Now, PostgreSQL could start successfully.
Hope it could help someone who met the same issue again.
This worked for me. First locate postmaster.pid (for me it was in the var directory as seen below, although it will be different on depending on your operating system). Then get rid of postmaster.pid, then kill the postgres process, then start/restart postgres service.
cd /var/lib/pgsql/data/
rm postmaster.pid
sudo pkill -u postgres
sudo systemctl start postgresql.service
If you have installed postgres with brew then simply run the following command and it will manage everything
brew services restart postgresql
I'm getting the following error when I try to run "mongod" in the terminal. I've tried uninstalling, reinstalling, and restarting the machine. Any suggestions on how to get it working would be amazing.
ERROR:
dbpath (/data/db) does not exist.
Create this directory or give existing directory in --dbpath.
See http://dochub.mongodb.org/core/startingandstoppingmongo
Side note:
Node also stopped working on my machine around the same time that I got this error.
events.js:72
throw er; // Unhandled 'error' event
^
Error: failed to connect to [localhost:27017]
Any help would be much appreciated!
This should work to ensure that the directory is set up in the right place so that Mongo can find it:
sudo mkdir -p /data/db/
sudo chown `id -u` /data/db
You need to create the directory on root /data/db or set any other path with the following command :
mongod --dbpath /srv/mongodb/
See the example link
I solved the problem with :
sudo mongod --dbpath=/var/lib/mongodb and then mongo to access the mongodb Shell.
Change the user of the new data directory:
chown mongodb [rute_directory]
And try another time to start the mongo service
service mongod start
I solve the same problem with this.
Daemons (usually ending with d) are normally started as services. Starting the service (daemon) will allow mongodb to work as designed (without permission changes if integrates well with your distro). I start it using the service named mongodb instead of starting mongod directly--on distro with systemd enable on startup then run like:
sudo systemctl enable mongodb
sudo systemctl start mongodb
or, on distro with upstart (if you have /etc/init) or init (if you have /etc/init.d) ( https://www.tecmint.com/systemd-replaces-init-in-linux/ ) instead run:
sudo service mongodb enable
sudo service mongodb start
If you have a distro with rc ("run commands") such as Gentoo (settings in /etc/init.d) (https://forums.gentoo.org/viewtopic-t-854138-start-0.html) run:
rc-update add mongodb default
/etc/init.d/mongodb start
In a distro/version of FreeBSD which still has rc (check whether your version switched to systemd, otherwise see below):
add the following line to /etc/rc.conf:
mongod_enable="YES"
then:
sudo service mongod start
After starting the service, an unpriveleged user can use mongo, and each user will have separate data.
I also got the error that "The file /data/db doesn't exist" when I tried to save my file using the "mkdir -p /data/db" command(using both with and without sudo command). But later on one site, a person named Emil answered that the path "/data/db" no longer works on Mac, so use "~/data/db" instead
i.e., use the command
mkdir -p ~/data/db
instead of previous command.
Moreover, use
mongod --dbpath ~/data/db
to run mongod
It worked for me, hope it work for others too facing the same problem
On fresh install of Ubuntu 14.04, I have installed mongodb 2.6.3 from mongo package,
problem is, that it does not start on reboot. It starts normally when I do
sudo service mongod start
and there are no errors in log file.
but when I reboot, log file has no new entries and
service mongod status
produces
mongod stop/waiting
I have tried mongod --repair, with no effect. I have tried fresh install of Ubuntu 14.04, as I thought that my older many times upgraded OS might have something wrong with it, but nothing changed.
With older version mongo that comes from ubuntu package manager, everything was starting up nicely.
Can you please give some advice on where to look to fix this issue and make mongod start up when system is booted up. Thanks!
Had the same problem. In the log file there was an:
************
Unclean shutdown detected
Please visit http://dochub.mongodb.org/core/repair for recovery instructions.
************
To solve this error, I just removed the lock file and it worked again.
sudo rm /var/lib/mongodb/mongod.lock
I believe the issue is that mongo upstart job checks if mongo is installed by the package manager. You need to edit the upstart job to use the new from-source binary location (which I think is /opt/mongodb/bin/mongod).
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.