I'm trying to connect to my db remotely, and having some trouble. A popular answer seems to be running
sudo rm /var/lib/mongodb/mongod.lock
sudo service mongodb restart
What are the consequences of running each of these commands? I am especially wondering:
Am I introducing potential problems by deleting the lock? Surely the lock must be there for a useful reason?
Will my data stay the same after the restart?
If mongodb is not running yet the lock file still exists, then your mongod service did not shut down gracefully (crashed). In this case, you can safely delete the lock file and your data will remain.
Related
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
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 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.
Something weird is happening with my postgres installation after I upgraded to version 9.3.2 homebrew.
Sometimes and not every time, if I enter psql I get this error message:
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
It also appears that postgres is running because if I try and stop postgres with this command:
pg_ctl -D /usr/local/var/postgres stop -s -m fast
I get this response:
pg_ctl: server does not shut down
If I look in the server.log I can see the following entries:
FATAL: lock file "postmaster.pid" already exists HINT: Is another
postmaster (PID 208) running in data directory
"/usr/local/var/postgres"?
After some frantic googling, I am able to cure this by entering these commands:
launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
rm ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
I would like to first of all understand what is happening and second of all I would like to fix it once and for all.
Can anyone explain what might be happening and a cure?
First, try to pull up a log on PostgreSQL, on OSX (and with PG 9.3) this will most likely be here:
/Library/PostgreSQL/9.3/data/pg_log
Check this log and see if there are any entires in it that may explain more of what is happening. Post it here or in a past bin somewhere. This can help the community to debug the issue.
Next, the reason why 'pg_ctl' says the server is not shutdown is because you have a stale socket file and/or a stale .plist file that did not get removed on last shutdown. This may indicate that the PostgreSQl daemon was "crashed" or was shutdown by force and did not have a clean finish.
The commands you used removed the stale files and thus made way for a new socket file to be created.
Also it is important to know if this was a minor or a major upgrade of PostgreSQL. Major upgrades always require a migration of the data directory. Running an old PostgreSQL data directory with a new engine might have unexpected results.
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.