I am working on rails project which I've cloned from GitHub. Because of other commitments, I have not been able to program for ~6 months, so I may have had an OSX update in this time.
I am getting an issue which I see others have had:
➜ isengarden git:(develop) rails db:create
could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
Couldn't create 'isengarden_development' database. Please check your configuration.
rails aborted!
PG::ConnectionBad: could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
/Users/joshua/code/JoshInLisbon/rails-projects/isengarden/bin/rails:9:in `<top (required)>'
/Users/joshua/code/JoshInLisbon/rails-projects/isengarden/bin/spring:15:in `<top (required)>'
./bin/rails:3:in `load'
./bin/rails:3:in `<main>'
Tasks: TOP => db:create
(See full trace by running task with --trace)
postgres.log:
2021-01-07 14:22:42.358 WET [86720] FATAL: database files are incompatible with server
2021-01-07 14:22:42.358 WET [86720] DETAIL: The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 13.1.
I am trying the solutions that have been set out on StackOverflow, but I would really like to know what is going on under the hood to make this error happen.
I have quite a limited understanding of DB fundamentals, so for me a problem like this is in a very opaque space, where I'm just copying and pasting solutions without an idea of why they might work.
Can anyone explain what is likely happening, and what the actual meaning is of my postgres logs?
Thank you
The version you have installed on your local computer is different from the postgres version with which the project was generated, when you change different versions you must be careful, since some functions are deprecated or renamed, in addition to the structure or form in which the data is saved also changes.
The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 13.1.
I suggest you install postgres version 11 and if you want to work with 13.1 then you must generate a backup and download it to a database generated with the current version
Related
We are having an issue with ssh level connection error, seems to be a timeout, during long deployments running our capistrano deploy with a large rails db migration task. Our only help has been moving these to rake tasks we manually run after deploy, not ideal. Any ideas within ruby/rails stack or outside to ensure ssh connection stays alive?
Errno::ECONNRESET, Connection reset by peer
Full trace:
** [deploy:update_code] exception while rolling back: Errno::ECONNRESET, Connection reset by peer - recvfrom(2)
/Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/net-ssh-2.9.2/lib/net/ssh/buffered_io.rb:65:in `recv': Connection reset by peer - recvfrom(2) (Errno::ECONNRESET)
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/net-ssh-2.9.2/lib/net/ssh/buffered_io.rb:65:in `fill'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:237:in `block in postprocess'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:233:in `each'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:233:in `postprocess'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/processable.rb:33:in `block in process_iteration'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/processable.rb:45:in `block in ensure_each_session'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/processable.rb:43:in `each'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/processable.rb:43:in `ensure_each_session'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/processable.rb:31:in `process_iteration'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/command.rb:171:in `block (2 levels) in process!'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/command.rb:170:in `loop'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/command.rb:170:in `block in process!'
from /Users/Ben/.rvm/rubies/ruby-1.9.3-p550/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
from /Users/Ben/.rvm/gems/ruby-1.9.3-p550#/gems/capistrano-2.15.5/lib/capistrano/command.rb:169:in `process!'
"Connection reset by peer" usually means that either the software on the remote end of the connection has crashed, or else some stateful firewall between the client and the server is interfering with the TCP connection.
In this case, the remote software ought to be the SSH server. And you say that this happens on long deployments. Given these things, I'd suspect that you have a NAT device or other stateful firewall between the client and the server, and it's dropping the TCP connection after some period.
You could try setting your client to send keepalive packets. I'm not a Ruby developer, but this page describes a keepalive option. Aside from that, you should talk to your network engineers to see if anything can be done about the device which is interfering with the connection.
So hopefully this helps someone else, think I found answer to my own question.
In our situation we had web and worker boxes both getting new deployment via capistrano. The web boxes were doing more expensive long running tasks like assets compile and publish to AWS S3 bucket. While this was happening our worker boxes became idle and timed out from no activity. capistrano detected this as an overall failure and rolls back release.
There are a few options here, like compiling rails asset pipeline resources ahead of time and even publishing to aws first, then starting other deployment steps.
We opt'd to just have our server's do client ping keep alives at ssh level
sudo vim /etc/ssh/sshd_config
Add these two lines to file:
ClientAliveInterval 60
ClientAliveCountMax 200
Note some sites mention just the first one, I found it didnt' work well unless putting second one also, as I suspect default max count is low.
ensure to restart ssh service after the change on each deployment target machine.
Just run rake db:migrate on your project before deploying it on server and after that run rake production deploy.
I am new to Ruby/Rails and PostgreSQL. Is it possible to have to multiple rails apps access a psql local database at the same, if not how do you switch between applications?
Currently RailsApp1 is interacting with my psql db as expected, however RailsApp2 cannot connect and rake commands abort.
Running on: OSX Mountain Lion, ruby 1.9.3p194, rails 3.2.8, psql 9.2.1.
~/RailsApp2 #: rake db:migrate
rake aborted!
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
Thank you in advance for the help.
PostgreSQL uses a client-server model, so the fact is you just connect to the server and multiple applications can make it work. Your specific problem sounds like the server isn't running or isn't accepting connections. Steps to try in order:
ps -A | grep post looking for postgres or postmaster processes. If not found start the server using the pg_ctl program.
Assuming it is running try setting the PGHOST environment variable to "localhost" so that it forces rake, psql, etc. to connect over TCP/IP. This would help if the UNIX socket is missing or just not where the client apps expect it to be.
If those two fail, find your postgresql logs (sometimes called serverlog, and sometimes in a pg_log directory) and post error messages.
I've researched this for a few hours now and I can't seem to find a solution.
I have a Rails 2 app that uses the TinyTds gem ( tiny_tds ) to connect to an SQL 2000 server hosted locally in our company.
The app has been connecting to SQL Server almost every day for the past 6 months with no problem.
Suddenly, when trying to connect yesterday, I started getting an error:
TinyTds::Error: Unable to open socket
from /var/lib/gems/1.8/gems/tiny_tds-0.4.5/lib/tiny_tds/client.rb:60:in `connect'
from /var/lib/gems/1.8/gems/tiny_tds-0.4.5/lib/tiny_tds/client.rb:60:in `initialize'
From my research, I've seen some people suggesting that I use
SO_REUSEADDR to allow it to connect and ignore timeout or "usage" restrictions, like this:
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR)
but I cannot figure out how to use that command within the current context.
I tried calling it in commmandline on the server and it won't work, but then again, I'm not sure what it does or if I can even call that from commandline.
I've tried calling
netstat -a
which shows current sockets, but I'm not sure what to do with that information.
I've also seen that
service restart
can restart a socket, but I'm not sure which socket to restart.
Lastly, in my freetds.conf configuration file, I have these settings:
host = 192.168.0.220
port = 1433
tds version = 8.0
I'm not really sure which road to take. I'm comfortable with Rails but this socket stuff is way outside my current understanding. This is also a Rails 2 app ( legacy ) which is key to some core processes our business uses. We can't upgrade to Rails 3 due to SQL server adapter gem for SQL 2000 Server won't work with Rails 3.
Can anyone help ?
I just updated my gems. And now I have problems connecting to my postgresql database. I get the error:
PGError
could not connect to server: Permission denied
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
I tried uninstalling the gem and reinstalling, I also tried to change the paths file and put '/usr/local/bin/' on top. I tried some of the things from post:
Repairing Postgresql after upgrading to OSX 10.7 Lion
This app worked fine before updating my gems, other apps still connect just fine, to the same server. I have the same settings in my database.yml file.. what could be wrong?
The error comes from the PostgreSQL server and I have seen it many times. It tells you that you are trying to connect via Unix domain socket (and not via TCP/IP!) to a server that is running locally and listening at port 5432. But no server can be found that would accept connections like that.
You did not mention where the PostgreSQL server resides - I assume you actually mean to connect to a database server on your local machine.
Check your setup, especially your pg_hba.conf file. You need a line like:
local mydb myuser md5
or
local all all peer
or some other connection method that includes your user and database.
These would not help in your case:
host ...
or
hostssl ...
They concern TCP/IP connections, not local connections via UNIX domain socket. When you connect to localhost you actually use TCP/IP via local loop and these settings apply.
Remember to reload after you edit pg_hba.conf. I quote the manual at the linked site:
If you edit the file on an active system, you will need to signal the
postmaster (using pg_ctl reload or kill -HUP) to make it re-read the
file.
This has been addressed some time ago, but I've not had any luck following the steps outlined or advice suggested. Here's my situation:
I've installed SQL Server '05 and have another (non-Ruby) application utilizing it successfully.
I've got Rails up and running successfully (but only for MySQL.)
I've installed the Rails sqlserver adapter gem (as well as its dependencies.)
I've downloaded ADO.rb (now only available on older builds of Ruby-DBI) and placed it into c:\ruby\lib\ruby\site_ruby\1.8\DBD\ADO\ADO.rb.
I've configured database.yml to use the sqlserver adapter and pointed it towards my database with valid login information.
When I attempt to run a migration, I get the ugly 'Unable to load driver ADO (uninitialized constant DBI::DBD::ADO)' error.
Thanks immensely for any assistance.
So just make sure if you're working on Windows or Mac to set up an ODBC connection. You must indicate this explicitly in your database configuration for Rails.