I am new to Symfony and Composer.
I recently installed Symfony 3 with the installer (on Linux) just as explained.
Afterwards I also installed Composer.
When I try to run an update with Composer it gives errors like:
post-update-cmd: Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap
PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Failed to write cache
file "/home/dev/var/bootstrap.php.cache".' in
/home/dev/vendor/symfony/symfony/src/Symfony/Component/ClassLoader/ClassCollectionLoader.php:236
and
[RuntimeException]
Unable to write in the cache directory (/home/dev/var/cache/dev)
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache handling the
post-install-cmd event terminated with an exception
[RuntimeException]
An error occurred when executing the "'cache:clear --no-warmup'" command:
[RuntimeException]
Unable to write in the cache directory (/home/dev/var/cache/dev)
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap handling the
post-install-cmd event terminated with an exception
[RuntimeException]
An error occurred when generating the bootstrap file.
I found some issues but they were old and seem to have a specific reason. I just cannot figure out what is going wrong.
I set the owner/group of /var to www-data which is the Apache 2 user. I set the write permissions for the group. Even tried 777 on /var/cache and bootstrap.php.cache.
It won't help.
When I delete the cache-dir it is created normally by Symfony. /var/cache/dev and /prod are also created and loaded with dirs and files.
I can't find bootstrap.php.cache anymore now.
How can I fix this?
If you are running Centos Linux, by default SELinux (/etc/sysconfig/selinux) is set to "enforcing" mode. This will prevent apache user or httpd process from writing to Symfony cache and log paths. Most people take the easy way out by setting to "permissive" mode and rebooting the OS.
The right approach is to leave SELinux in "enforcing" mode and use policycoreutils-python to change some permissioning. These instructions assumes you have used setfacl as per Symfony2 docs.
sudo yum install policycoreutils-python
sudo setsebool -P httpd_can_network_connect 1
sudo setsebool -P httpd_enable_cgi 1
sudo setsebool -P httpd_builtin_scripting 1
sudo setsebool -P httpd_unified 1
sudo setsebool -P httpd_read_user_content true
sudo setsebool allow_httpd_anon_write true
sudo setsebool -P httpd_can_network_connect_db 1
sudo restorecon -rv /var/www
Related
I have a python script that does calculations on google compute engine instances. The code works fine in terms of doing the calculations, but at certain points in the code it needs to add/delete files from a cloud storage bucket and I do this using gsutil. This works well when run from my local computer, but isn't working when the same code is run from a google cloud instance. By "not working" an error message is reported at the offending line, but my code carries on running and just ignores the steps that involve gsutil.
My understanding from Google's documentation is that gcloud instances boot with the "gsutil" utility already installed. My instances boot running a script like this (where is my actual google username):
#! /bin/bash
sudo apt-get update
sudo apt-get -yq install python-pip
sudo pip install --upgrade google-cloud
sudo pip install --upgrade google-cloud-storage
sudo pip install --upgrade google-api-python-client
sudo pip install --upgrade google-auth-httplib2
mkdir -p /home/<xxxx>/code
mkdir -p /home/<xxxx>/rawdata
mkdir -p /home/<xxxx>/processeddata
sudo chown -R <xxxx> /home/<xxxx>
gsutil cp gs://<codestorebucket>/worker-python-code/* /home/<xxxx>/code/
gsutil -m cp gs://<rawdatabucket>/* /home/<xxxx>/rawdata/
I dont run my code from the boot script yet as I want to "SSH" into the instance and run it myself from the command line while I am still developing. When I SHH into the instance the directories have all been created and all of the code and raw datafiles have been copied. I can run my ".py" file and it runs, but there are lines which use the python command:
subprocess.call('gsutil -q rm gs://<mybuckname>/<myfilename>', shell=True)
This generates an error which reads:
ERROR: (gsutil) Failed to create the default configuration. Ensure your have the correct permissions on: [/home/<xxxx>/.config/gc
loud/configurations].
Could not create directory [/home/<xxxx>/.config/gcloud/configurations]: Permission denied.
If it provides any clues, in the "daemon.log" file there an error line which reads:
chown: invalid user: ‘<xxxxx>’
which is reported when the sudo chown... command line runs.
The instances have full access to all APIs. If I run
whoami
The response is "xxxxx". If I run
echo $UID
The response is 1000.
I am a Linux novice, as I have only "learnt" about it through needing to do stuff on google instances. There is a link here where a user appears to have a similar problem. He fixes it using a sudo chown type command line, but when I run an equivalent command I am told that it "cannot access '/home/paulgarlick07/.config/': No such file or directory"
I'm really confused, and any help would be very much appreciated. If any additional info is required to help resolve this please let me know!
gsutil is not a program. It is a script. Therefore you need to execute a shell with gsutil as a command line argument. You will need to pass the full pathname for gsutil which might be different on your system.
subprocess.call('/bin/sh /usr/bin/gsutil -q rm gs://<mybuckname>/<myfilename>', shell=True)
If you are running gsutil from a service, then you will need to ensure that the user that the service is running under has gsutil setup. gsutil stores its configuration files based from the home directory of the user that it is executing under.
I am trying to setup a queue listener for laravel and cannot seem to get supervisor working correctly. I get the following error when I run supervisorctl reload:
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 228
The file DOES exist. If try to run sudo supervisorctl I get this
unix:///var/run/supervisor.sock no such file.
I've tried reinstall supervisor and that did not work either. Not sure what to do here.
I'm running Laravel Homestead (Ubuntu 16.04).
Result of service supervisor status:
vagrant#homestead:~/Code$ sudo service supervisor status
● supervisor.service - Supervisor process control system for UNIX
Loaded: loaded (/lib/systemd/system/supervisor.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2016-12-22 11:06:21 EST; 41s ago
Docs: http://supervisord.org
Process: 23154 ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown (code=exited, status=0/SUCCESS)
Process: 23149 ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf (code=exited, status=2)
Main PID: 23149 (code=exited, status=2)
You should run sudo service supervisor start when you are in the supervisor dir.
Worked for me.
2020 UPDATE
Try running sudo service supervisor start in your terminal before using the below solution. I found out that the issue sometimes occurs when supervisor is not running, nothing complicated.
I am using Ubuntu 18.04. I had the same problem and re-installing supervisor did not solve my problem.
I ended up completely removing the conf.d directory and recreating it with new configs. Make sure you back up your configurations before trying this:
sudo rm -rf /etc/supervisor/conf.d/
sudo mkdir /etc/supervisor/conf.d
sudo nano /etc/supervisor/conf.d/my-file.conf
Copy+Paste your configuration into your new file.
sudo supervisorctl reread started working again.
In Ubuntu 18.04 with distribution's package
You probably did the same mistake as me an created the config file /etc/supervisord.conf while my service manager (systemd) was using the config file /etc/supervisor/supervisord.conf
Solutions
Remove the config file created
sudo rm /etc/supervisord.conf
Move it to the correct location
sudo mv /etc/supervisord.conf /etc/supervisor/supervisord.conf
Now you can run sudo supervisorctl
Why?
when you run supervisorctl it first searches for the config file located at /etc/supervisord.conf, if it's not present, it will search for the package's default file /etc/supervisor/supervisord.conf this is the one systemd actually runs.
Systemd always use the file /etc/supervisor/supervisord.conf regardless of the other file's existence.
You can check which file is using systemd by running sudo systemctl status supervisor
You can see in the last line the command where the config file is hardcoded
I had a very similar problem (Ubuntu 18.04) and searched similar threads to no avail so answering here with some more comprehensive answers.
Lack of a sock file or socket error is only an indicator that supervisor is not running. If a simple restart doesn't work its either 1. not installed, or 2. failing to start. In my case nothing was being logged to the supervisor.log file for me to know why it was failing until I ran the following command (-n to run in foreground) only to find out that there was a leftover configuration file for a project that had been deleted that I missed.
/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
Once I deleted the bad/leftover file in the conf.d folder and started it back up with sudo service supervisor start everything worked.
Here are some comprehensive steps you can take.
Is supervisor installed? dpkg -l | grep supervisor If not reinstall sudo apt install supervisor
Are all instances of supervisor stopped? systemctl stop supervisor Lingering supervisor processes can be found ps aux | grep supervisor then kill -9 PID.
Is supervisor.conf in the right location /etc/supervisor/supervisor.conf and there are no syntax errors? Reinstall from package would correct this.
Move your specific files in conf.d/ temporarily out of the folder to try and start with no additional config files. If it starts right up sudo service supervisor start the likelihood of an error in your project .conf file exists.
Check status with sudo service supervisor status.
Move your .conf files one by one back into conf.d/ and restart sudo service supervisor restart. Be sure to check with sudo service supervisor status between. If it fails you know which .conf file has an issue and can ask for specific help.
check everything is running with supervisorctl status and if not start with supervisorctl start all.
None of about answers helped me.
the problem was i didn't follow supervisor documentation.
and a step i didn't do was run echo_supervisord_conf command that makes the configuration file.
Steps i did for Ubuntu 18.04:
Installing supervisor (without pip):
sudo apt-get install supervisor
echo_supervisord_conf > /etc/supervisord.conf (with root access: first run sudo -i then echo_supervisord_conf > /etc/supervisord.conf)
change python dependency to python2
(Depends: python-pkg-resources, init-system-helpers (>= 1.18~), python-meld3, python:any (<< 2.8), python:any (>= 2.7.5-5~)
in these files: /usr/bin/supervisord | /usr/bin/supervisorctl | /usr/bin/echo_supervisord_conf.
Just change the first line from #!/usr/bin/python to #!/usr/bin/python2
run supervisord
Finish
hope help !
Facing the python file not found an error, code=exited, status=2 once I try with the official document but still same.
I have tried so many solutions for my laravel application.
But at last, I have tried with my solution.
Here is an example for the code :
[program:dev-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/example.com/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
user=ubuntu
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/html/example.com/storage/logs/laravel.log
stopwaitsecs=3600
Ref: https://laravel.com/docs/7.x/queues#supervisor-configuration
I ended up just removing supervisor entirely, reinstalling and rewriting my config files. I must have just done something wrong in the process and wasn't able to catch it.
You can try by removing all of the related folder of supervisor & uninstall supervisor completely.
sudo rm -rf /var/log/supervisor/supervisord.log
sudo rm -rf /etc/supervisor/conf.d/
After doing this, reinstall supervisor by
sudo apt install supervisor
Now, you can run correctly. Check with
sudo systemctl status supervisor
If by running sudo service supervisor status you get the following:
ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf (code=exited, status=2)
Try running /usr/bin/supervisord, it will give you clear message to tell you where the error is.
On Centos 7 I use the following...
supervisord -c /path/to/supervisord.conf
followed by...
supervisorctl -c /path/to/supervisord.conf
This gets rid of the ".sock file not found" error. Now you have to kill old processes using...
ps aux|grep gunicorn
Kill the offending processes using...
kill <pid>
Then again...
supervisorctl -c /path/to/supervisord.conf
Supervisor should now be running properly if your config is good.
Check the supervisord.conf file.
Look for the following:
[unix_http_server]
file=/path/to/supervisor.sock/file ; (the path to the socket file)
chmod=0700 ; sockef file mode(default 0700)
Go to the path mentioned above and check if the file is present.
If it is present then try re-installing supervisor.
If not then search for supervisor.sock file either using the command line or file explorer GUI.
Copy the file found in the above step to the location specified in the [unix_http_server] by using the cp command or GUI.
For me, the supervisor.sock was present in the /run folder.
you can try
sudo touch /var/run/supervisor.sock
sudo chmod 777 /var/run/supervisor.sock
I ran into this issue because we were using supervisorctl to manage gunicorn. The root of my problem had nothing to do with supervisor (it was handling other processes just fine) or the python sock.py file (file was there, permissions were correct), but rather the gunicorn config file /etc/supervisor/conf.d/gunicorn.conf. This configuration file was managed by a source-controlled template with environment variables and when we updated the template on the server, the template variables were never replaced with the actual data. So for example something in the gunicorn.conf file read user={{ user }} instead of user=gunicorn. When supervisor tried to parse this config when running supervisorctl start gunicorn it would crash with this socket error. Repairing the gunicorn.conf file resolved the supervisor issue.
Source of answer : http://supervisord.org/installing.html
Run command : echo_supervisord_conf
Once you see the file echoed to your terminal, reinvoke the command as echo_supervisord_conf > /etc/supervisord.conf. This won’t work if you do not have root access.
If you don’t have root access, or you’d rather not put the supervisord.conf file in /etc/supervisord.conf, you can place it in the current directory (echo_supervisord_conf > supervisord.conf) and start supervisord with the -c flag in order to specify the configuration file location.
The error should've been resolved by now.
I did the following to solve the issue on CentOS Linux 7
sudo systemctl status supervisord.service
With the above command, I realise that the program was in active
sudo systemctl start supervisord.service
Now I use the command above to start the service and everything works well now
I installed elasticsearch this way :
retrieved the tar.gz on windows, extracted it and put it on a zip
uploaded the zip over ssh on a server and use 'unzip file' to unzip it.
I modified the elasticsearch file so that it has this line
export JAVA_HOME = "/home/xxx/project1/jdk1.8.0_73_linux64"
just below
#!/bin/sh
now when I go into /home/xxx/project1/elasticsearch/bin and type
./elasticsearch
I get
-bash: ./elasticsearch: Permission denied
What could I do to get more information about the problem?
I'm logged as user xxx
Thanks.
The problem is, that you've installed elastic being logged in as root. Now you're surely logged in as not root. If you're working as a user with root privileges, you potentially could start elastic, but it tells you, you can't run in as root. The owner of your elastic folder is root (he installed it). So, all you need to do is to change the owner of a folder to your xxx-user (to let him run elastic). You can easily do it executing a command:
chown -R new_owner path
for example, user is xxx and path is /opt/elasticsearch-2.3.5:
chown -R xxx /opt/elasticsearch-2.3.5
"-R" parameter ensures, that not only folder, but all files inside will recursively change the owner you provide.
Try to install using the package Yum Install for elasticsearch.
Else try: Its sounds like the user permission to access the files.
Ensure that you have downloaded the linux distribution (Optional) Since you have mentioned its tar.gz.
If you have extracted using sudo command then you need to change the user permission for elasticsearch folder to logged in user OR start the elasticsearch using sudo command
sudo ./elasticsearch -d
Check the execution permission if not please do the same by following command
sudo chmod +x /home/xxx/project1/elasticsearch/bin/elasticsearch.sh
Try this things if not please create a chat window and invite me.
Looking ahead I will immediately say that the ES app doesn't work using the sudo
In my case with ES 6.8.1 version on ubuntu i solved the problem using this steps:
Add the current user(or any other) to ES group:
sudo adduser <yourName> elasticsearch
Add possibility to execute ES:
sudo chmod +x /usr/share/elasticsearch/bin/elasticsearch
Then i changed owner of some paths**, in my case these were:
sudo chown -R <yourName>:elasticsearch /etc/default/elasticsearch
sudo chown -R <yourName>:elasticsearch /etc/elasticsearch
sudo chown -R <yourName>:elasticsearch /var/log/elasticsearch
**I started the application several times and then looked where I had no permission
Then i started ./usr/share/elasticsearch/bin/elasticsearch and saw the long-awaited JSON on port 9200 :)
Hope this will help someone.
I am working on installing another version of ruby on another server which is CentOS 6.7 When while trying to configure ruby within the tmp directory I receive a:
sudo: unable to execute ./configure: Permission denied
Here is exactly what I am doing leading up to this:
mkdir /tmp/ruby && cd /tmp/ruby
curl --progress ftp://ftp.ruby-lang.org/pub/ruby/2.1/ruby-2.1.2.tar.gz | tar xz
cd ruby-2.1.2
./configure --disable-install-rdoc <!-- here is were we fail with permission denied
I am currently logged in as root. I have played around with changing my file permissions and that did not seem to help at all.
Any suggestions?
From this link it appears /tmp is mounted as read-only.
Open /etc/fstab, find the line that mounts your /tmp dir, and remove the noexec flag. Then remount the filesystem (or simply restart your system).
As a side note, you will also want to avoid running ./configure and make as root user. Only when it comes to run make install should you run as root.
I installed Postgresql 9.4.0 installed on my Mac (10.10.1/Yosemite) using homebrew. It does not work.
I have created the softlink to /usr/local/opt/postgresql/homebrew.mxcl.postgresql.plist in ~/Library/LaunchAgents.
If I try to manually load postgres I get the message that the "Operation is in progress"
> launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
/usr/local/Cellar/postgresql/9.4.0/homebrew.mxcl.postgresql.plist: Operation already in progress
However postgres does not appear to be running.
> ps auxw | grep post
billmcn 670 0.0 0.0 2424272 452 s000 R+ 10:12PM 0:00.01 grep post
and I cannot connect with the command line client.
> psql
psql: 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"?
To my knowledge I have tried all the fixes suggested on other Stackoverflow threads discussing this problem. Specifically:
I have uninstalled and reinstalled postgres and the accompanying Ruby gem. There is no postgres 8.0 version on my machine.
I have verified that the psql client program is the 9.4.0 version installed by Homebrew and not a Mac system binary.
I have verified that the /usr/local/var/postgres/postmaster.pid does not exist.
I have rebooted the machine.
I did have Homebrew postgres working on this machine earlier. I think what broke it is upgrading from version 8 to version 9 but I'm not sure.
I don't have any databases I need to preserve. I'm willing to start clean with postgres; I just need to get it to work now. Any ideas?
The issue appears to have been permissions on the /usr/local/var/postgres directory. Here is what my var directory looked like when things weren't working.
ll /usr/local/var/
drwxr-xr-x 3 billmcn admin 102 Dec 20 12:44 cache
drwxr--r-- 2 root admin 68 Dec 29 21:37 postgres
(whoami = "billmcn")
I deleted /usr/local/var/postgres, uninstalled and reinstalled postgres, and now it looks like this.
ll /usr/local/var/
drwxr-xr-x 3 billmcn admin 102 Dec 20 12:44 cache
drwx------ 23 billmcn admin 782 Dec 30 10:51 postgres
Not sure how it got into this state because I don't remember futzing with the permissions on this directory, but no matter. It works now.
I had the same problem installing postgres using homebrew on a freshly installed Yosemite.
First off my brew config looks like this:
HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/Homebrew/homebrew
HEAD: 9f6926265f8e4be7cc80dfe9042f2cd3c1e8dc9e
Last commit: 64 minutes ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: quad-core 64-bit sandybridge
OS X: 10.10.1-x86_64
Xcode: 6.1.1
Clang: 6.0 build 600
X11: N/A
System Ruby: 2.0.0-481
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: ~/.rvm/rubies/ruby-2.1.1/bin/ruby
First thing i noticed was that I had no write permission to /usr/local/var/postgres. This was easily changed issuing sudo chown -R `whoami` /usr/local/var/postgres then I reinstalled postgresql and did
cat /usr/local/var/postgres/server.log
which revealed:
postgres cannot access the server configuration file "/usr/local/var/postgres/postgresql.conf": No such file or directory
So I removed the directory /usr/local/var/postgres and issued the command to initialize the database.
initdb -D /usr/local/var/postgres/
This seemed to have done the trick and postgres is running fine.
I had this same problem. The primary issue here is that the initdb step of installation will create the directory with root ownership instead of as the user on a Mac. To solve this issue:
Create the data directory before running initdb and set permissions of 0700
rm -rf /usr/local/var/postgres # in case this is not your first try
mkdir /usr/local/var/postgres
chmod 0700 /usr/local/var/postgres
Then run initdb and it will respect the permissions of the data directory.
initdb -D /usr/local/var/postgres
For grins and giggles, create a test db named after your user:
createdb `whoami`
Login to test:
psql
After trying to install postgresql with Homebrew, I got this:
Warning: postgresql-9.5.2 already installed, it's just not linked
So I tried:
brew link postgresql
And got this error:
Linking /usr/local/Cellar/postgresql/9.5.2...
Error: Could not symlink share/man/man3/SPI_connect.3
/usr/local/share/man/man3 is not writable.
It seemed to be a write permission matter, so I did:
sudo chown -R `whoami` /usr/local/share/man/
It did the trick because, then I was able to do (without error):
brew link postgresql
In case anyone upgraded from a previous version, dont forget to:
brew postgresql-upgrade-database
That will solve the problem by upgrading your existing databases to the version you upgraded postgres to.
Please note that their is a thread on Homebrew's github dealing with this issue: https://github.com/Homebrew/homebrew/issues/35240
I have had a similar issue. James answer helped me solve it. But I then ran into the issue jbk is mentioning (after having deleted /usr/local/var/postgres, it kept on being recreated).
The issue is that if you have created the symlink:
ln -sfv /usr/local/opt/postgresql/*.plist ~/Library/LaunchAgents
and launched the process:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
you should first unload it:
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
before running James's commands.
rm -rf /usr/local/var/postgres # in case this is not your first try
mkdir /usr/local/var/postgres
chmod 0700 /usr/local/var/postgres
In addition, if, like me, you have an admin user managing homebrew and a regular user who will be using pgsl for development purpose, James command should be run as super user:
sudo -s
and ownership over the postgres directory should be given to your dev user:
chown my-dev-user /usr/local/var/postgres
The following command, run as the dev user, should then properly populate the directory:
createdb `whoami`
Running:
psql -l
should show you the tables and user permissions in postgre after such manipulations.
Hope this helps.
I had to delete the .pid file after seeing this in the logs
/usr/local/var/log/postgres.log
2021-10-10 19:05:27.468 BST [41868] FATAL: lock file "postmaster.pid" already exists
2021-10-10 19:05:27.468 BST [41868] HINT: Is another postmaster (PID 820) running in data directory "/usr/local/var/postgres"?
rm /usr/local/var/postgres/postmaster.pid
I installed it using brew
based on #James answer this is what I did on my M1 Monterey machine. For me the directory differed.
DANGER: In the comments it has been pointed out that my script deletes the database.
In terminal:
#to fix postgresql of existing installation
cd /opt/homebrew/var
rm -rf postgres
mkdir postgres
chmod 0700 postgres
initdb -D postgres
#install postgres
echo "installing postgres..."
brew install postgresql
brew services restart postgresql
createuser postgres -s
I then could brew install --cask pgadmin4 and run pgadmin from Applications and connect to 127.0.0.1.
I recently had a problem which began when I upgraded some brew updates / upgrades, mainly python versions etc. What worked for me.
brew uninstall postgres
brew install postgresql#9.5
echo 'export PATH="/usr/local/opt/postgresql#9.5/bin:$PATH"' > ~/.zshrc
# you may need > ~/.bashrc if you use bash
I needed pg_dump, pg_restore etc so to get that working I did
brew install libpq
Start the service
brew services start postgresql#9.5
From here I would have expected everything to work but still all rails db commands were giving error that server was not running. This final bit was the missing piece of the puzzle which finally solved it for me.
gem uninstall pg
gem install pg -v 0.20.0 # which was set in Gemfile
# could also just probably do bundle install instead.
For posterity, I had this issue and wanted to note what worked for me.
I am running postgres 11.2 on High Sierra. I had recently upgraded from postgres 10 with brew postgresql-upgrade-database.
I kept getting the error psql: could not connect to server: No such file or directory, and my server.log indicated is another postmaster (PID 5894) running in data directory "/usr/local/var/postgres"?
I tried several solutions including restarting my computer, deleting postmaster.pid, using brew services restart postgres, but to no avail. I eventually stumbled on the solution:
brew unlink postgresql && brew link postgresql
No idea why this worked, but putting it here mostly so I can reference it myself in the future! Throw stuff at the wall till it sticks!
Check #leo_chaz_maltrait for fixing errors the error Could not symlink share/man/man3/SPI_connect.3
Another error that might show up is:
Error: Could not symlink lib/pkgconfig/libecpg.pc
sudo chown -R `whoami` /usr/local/lib/pkgconfig
brew link postgresql
Please read and follow the instructions.
Check postgres logs to see what the issue is.
tail -f /usr/local/var/log/postgres.log
tail -f /opt/homebrew/var/log/postgres.log
tail -f /usr/local/var/postgres/server.log
In my case it this was the error.
2022-07-19 21:16:12.095 IST [2138] FATAL: data directory "/usr/local/var/postgres" has invalid permissions
[3472] FATAL: lock file "postmaster.pid" already exists
Added the required permission and issue got fixed.
sudo chown -R vikas /usr/local/var/postgres
rm /usr/local/var/postgres/postmaster.pid
That's it.
I'd this issue after shutting down the computer due power outage.
# This initialize your database with the current data and settings
initdb -D postgres
# This will start database service
pg_ctl -D postgres -l logfile start