Closed jeroenbourgois closed 5 years ago
Can you please include your mix.exs, as well as the output of “mix deps”? Thanks. --
José Valim www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D
@josevalim yes, of course! I updated the original ticket.
So @jeroenbourgois, the only way this error can happen is if you have a bad extension. Maybe the remote server is configured in different ways than the local one?
Do you have anything else being logged? If not, you can try by adding :sasl
to :extra_applications
in your mix.exs
and then adding this configuration to production:
config :logger, handle_sasl_reports: true
This should report much more data and hopefully link to the root clause.
@josevalim the remote server is a Amazon RDS, but I do not know that much about it. I added sasl
, thanks for the tip! It did provide a lot of output, amongst which I can see the Postgrex.TypeManager being started. However, sadly, the output ends with the same output as above.
The output in between is: Start Call: Registry.start_link(:unique, Postgrex.TypeManager)
We will try to find something on the Amazon RDS side. Can you provide information on what extension exactly should be enabled?
Can you please put the full output in a gist? Thank you. --
José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Director of R&D
@josevalim absolutely -> gist
This is so weird. We can see the TypeManager is started and it never terminates but it still cannot be found. Have you deployed it to production before or is this the first deployment? If the latter, can you try connecting from your machine to the production DB to give things as a try?
@josevalim weird indeed 😄 . From OSX, I can connect to them just fine. On the machine itself I tried telnet-ing the RDS which worked, but I don't know of a better way to check that since the staging server has no Postgres installed.
I just spinned up a brand new RDS instance on Amazon on another account, and at first I was unable to curl/telnet to it from the machine, so I saw another more clear Ecto error. Then, once I could connect again from curl, the old errors from above were back. This is so sad, the project is as good as finished, I put off testing on staging because I thought 'it is just the db setup, deploy, run migrations, done'. Not 😛
@josevalim I just copied over my app to the remote machine and compiled it over there. Then, when done, I ran it using iex -S mix
and it just worked... So there is something with the generated release that is causing the problems I guess. Still need to figure out what, because I don't want to run the app like that, we prefer to deploy with edeliver. But this might give someone a clue?
Also, and this might be important, I recently renamed the whole app from x to y, maybe that is causing some issues somewhere? But then, since I can run the app through iex, this does not seem to be the case.
@josevalim solved! I kept on digging to try to find out what had fundamentaly changed in the app that could cause something like this that also had something related to releases.
My eye fell on this output (also in the gist above): 17:29:01.813 [info] Application mix started at :"my_app@127.0.0.1" Starting dependencies.. Starting repos.. Running migrations for my_app 17:29:02.308 [error] GenServer #PID<0.136.0> terminating
The 3 lines without thimestamp were not output by the Logger, but probably with IO.puts
Also the to dots instead of three made me realise it had to be something not from distillery/mix/elixir itself.
Then I realised my coworker had finished a long overdue task we had about having a proper setup regarding release tasks with distillery, and the release hooks that are available. He did a good job on one project and then migrated that solution to our other existing projects. All of our projects use MySQL as a db, so the release task started :mariaex
before running migrations.
All projects, except this one... So postgrex
was not started before running the migrations and seeder, thus causing an error.
Still, the error was very ambiguous for me, I hope my explanation of the actual cause can maybe help to improve error logging in the future, because if the IO.puts calls would not have been there, there would be no indication it was related to that.
So happy it works now!
PS: is there any benefit and/or downside to leaving the sasl
app in the setup? Does it slow down the app? If not, would it not be good practice to include it all the time? It is new to me.
Glad to hear. Having sasl on is totally fine and even recommended. It should not slow anything down. --
José Valimwww.plataformatec.com.br http://www.plataformatec.com.br/Founder and Director of R&D
I was using RDS and I ended up with having a space at the end of my RDS URL. It's weird how the error was reported. Removing the space solved the issue.
Hi
I have a running Phoenix app connected to a Postgresql db, which is running fine on my local machine. However, after deploying, I get the following error (4 times):
The main difference between my local and online setup is that the former has a postgres server running locally whereas the latter connects to a remote Postgres db. Does the online machine requires something installed before being able to connect to a remote machine?
For now, it is only a basic Debian machine, nothing db-related installed.
Thank you!
FYI:
Remote psql: PostgreSQL 10.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9), 64-bit Elixir 1.7.4 Erlang/OTP 21 [erts-10.2]
Output for
mix deps
:My
mix.exs
: