After upgrading GitLab, two different psql/postgres versions - postgresql

We recently did a GitLab upgrade from 11.x up to 12.9.2. It all went well; however, when I do gitlab-ctl pg-upgrade it shows the DB being 10.12. But when I do gitlab-rake gitlab:env:info it shows 10.7.
If I drop into gitlab-rails dbconsole it shows:
psql (10.12, server 10.7)
I didn't originally set this server or instance up. Any idea why it would be showing two different versions (does 10.12 mean the client is 10.12, the server is still 10.7?) Ideally the server would be 10.12.
Thanks for any help.

Answered my own question after further digging.
I ran a stat on /opt/gitlab/embedded/postgresql/10/bin/postgres and it showed that it was indeed changed when we did the upgrade.
Then I ran an lsof and saw that the postgres process had this binary open with a (deleted) marker, meaning it had the previous file still open in memory.
I ran a gitlab-ctl stop and a gitlab-ctl start and now it's showing properly when I do gitlab-rails dbconsole.
Should've done all that first!

Related

Error: Permission denied # rb_sysopen - /Library/LaunchAgents/homebrew.mxcl.mongodb-community.plist

Getting the above error when I try to install Mongo with homebrew from terminal. I've seen a lot of people with this same issue but none of the past recs have worked for me. I'm on an M1 Macbook Pro. Any help?
I run into the similar problem on M1 Mac PRO. I guess that your MongoDB is up and running. so if you run
$brew services start MySQL/MongoDB
System fails to grab the service (since it starts already) and returns the the error.
My solution is to uninstall MySQL. install it again. And restart the machine.
Once restarting the machine, check whether MySQL is running by
$mysqld
The system shown that SQL is up and running. then do
$mysql -uroot

Cannot find PostgreSQL files, clusters, or service; what to do?

I am currently trying to install and setup PostreSQL on my computer (Debian 9) so I can use it as a local testing environment for Heroku. I have been having some problems. First, whenever I try to run psql (and similar commands), I get this error:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
I have looked around on here for some fixes to this, such as this one, however I cannot find the postmaster.pid anywhere inside /usr. When looking for /var/run/postgresql, my search also turned up nothing.
Another promising answer was this one, however, I run pg_lsclusters, none appear. From a bit of searching, it says that this is probably due to initdb never being ran. I looked around for several ways to do this manually; none of them have worked or appear to exist on my system.
I have tried many of the "simple" things, such as sudo, sudo su postgres, removing and reinstalling the package and screaming at the computer.
What exactly is going on here? How do I fix it?
My OS (as mentioned before) is Debian 9, and the psql --version (which does work) is psql (PostgreSQL) 10.4 (Debian 10.4-2.pgdg90+1).

Error when opening pgAdmin 4 on mac

I have installed version 4-1.5, but when opening it, it always shows this error "The application server could not be contacted."
I removed the local directory hidden and resolved:
$ cd ~
$ rm -r .pgadmin/
Note: macOS Sierra (10.12.6) and pgAdmin 4-1.6. Also you are going to loose configuration data like database list tree, et al.
The Databases will remain intact since you are modifying/deleting PgAdmin related data not any of Postgresql itself.
I had the same issue, I fixed it by stopping the service in Postgres app, then start pgAdmin, and then start the Postgres service. I was able to connect it after that. Hope this help.
I had same error, but in my case I use wrong port number for the database
On my system Safari is the problem as it was default browser.
To fix, make Chrome your default browser and try relaunching pgadmin4
OR
Manually fix by
$ cat ~/.pgAdmin4.5704814747986328352.addr
http://127.0.0.1:62631/?key=0ec25e6a-dfe2-483e-9814-b315ea87c3cf
Paste what you get in Chrome

Stuck in starting meteor

This is really frustrating me. I have a DO VPS with ubuntu 14.04 (64) installed.
I installed VestaCP as control panel on that and have hosted some PHP based personal project.
I also installed meteor on it but never used, now when I am trying to create a project and run it ('meteor create rt' then 'cd rt' then 'meteor')
It is giving the following error :
[[[[[ /home/admin/code/rt ]]]]]
=> Started proxy.
Unexpected mongo exit code 1. Restarting.
Unexpected mongo exit code 1. Restarting.
Unexpected mongo exit code 1. Restarting.
Can't start Mongo server.
root#RD:/home/admin/code/rt#
Could anyone please help? Please ask me for more informations if required.
**** EDIT ****
I created a fresh DigitalOcean server and it is giving the same error on that. Some issue with Digital Ocean? File System of Digital Ocean? I am confused. I am trying it on different flavours of Linux and same result. All are fresh linux installations.
I finally got the solution. Posting it here for others.
This was the problem as a few environment variables which mongodb looks for while starting was not set
Set the variables LC_ALL and LANG and it works fine (mostly setting LC_ALL will do)
first, type locale command and see the output, you will see that it will say something about LC_ALL not set.
Now, add these two lines in /etc/environment and it worked.
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
This solution is for Ubuntu 12.04 +
Other variants may require similar work.
Unexpected mongo exit code 1 is still an uncaught exception as far as i think.
You can try by updating your c/c++ compilers uptodate. Have a look here.
It says :
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.6
sudo apt-get install g++-4.6
All the best!
So we have narrowed the issue down to meteor's mongo installation on your box (though I think we were pretty sure of this all along). Let's attempt to debug that a bit. The way I have done this in the past is to try to open meteor's mongo with the mongod provided by meteor. You will perform these procedures without running the meteor server. This should give you the warning that is causing Mongo to exit. First you need to find this. In my instance installed on Mint (which should be similar to Ubuntu) it is at:
~/.meteor/packages/meteor-tool/.1.1.3.4sddkj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/mongodb/bin/mongod
You can look at that location on your Ubuntu box or you can run something like this to get the location:
find ~/.meteor/ -name mongod
Once you find the location then go to the directory of your meteor project you are attempting to run and in that directory you should find this location:
<your meteor project>/.meteor/local
cd into that directory and run the following command:
~/.meteor/packages/meteor-tool/.1.1.3.4sddkj++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/mongodb/bin/mongod --dbpath ./
From there you can analyze the output (or update the question so we can see the output) and this should show you the mongo error you are receiving on startup and allow you to fix it.
I've got the same issues trying to start a meteor app and exactly the mongodb server is being terminated in an unexpectly manner. Generally the virtual linux server from some dealers like the one you mentioned are coming without a swap partition (check in /etc/fstab file) so if you have not enough memory to allocate MongoDB server then meteor app can't be started. You can create a swap partition or instal swapspace
sudo apt-get install swapspace
After that I was able to start the meteor app... Just be patient as swap memory is not as faster as RAM.
Since due some "smart" StackExchange policy I cannot up-vote or comment to working solution...)
Quoted answer works also on Digital Ocean on CentOS 7 x64 vmlinuz-3.10.0-123.8.1.el7.x86_64
first, type locale command and see the output, you will see that it will say something about LC_ALL not set.
Now, add these two lines in /etc/environment and it worked.
I changed the locale setting to match my needs.
Fixed on my Debian 8 with the following bash command, (use sudo if needed)
localedef -i en_US -f UTF-8 en_US.UTF-8

postgres sometimes will not start after reboot

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.