-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gatling not providing port? #38
Comments
Hi Evan, thanks for the feedback! What does your Can you open up |
@dennisreimann Thanks for the quick reply! The /etc/init.d/tracker and /etc/nginx/sites-enabled/tracker files both contain the port number, see below. I've been able to get the site up by inspecting them to get the port number and then running the release directly ( Will try executing those lines manually and post a follow-up. /etc/init.d/tracker:
/etc/nginx/sites-enabled/tracker
|
I have to provide a port at the command line to load the app in iex (else I get the same error as above) but once I do the function you linked seems to be able to identify a port just fine:
|
I'm going to add an issue about the other problem I'm having, in case it's related. |
I didn't mean to boot up the app with iex. Just start a normal iex session without any params outside the project folder and see whether or not getting the port number works :) |
The reason I booted the app is that (ashamed to admit this) I didn't otherwise know how to load an external library in an iex session. This morning I figured it out, though, so here you go:
The port number isn't the same as what in nginx config, but I assume that's because the app is currently running, so 39491 is no longer available. |
I tried a complete re-set today, deleting all relevant files on the server and starting over with a fresh install of gatling. I'm sorry this is so long -- but since we're 9 hours apart i thought it would reduce iteration time to include everything. Here are my config files, and I'll put the transcript of my attempt to deploy in the next post. Interestingly: the site actually came up, despite the errors, which were the same as before. however I wasn't able to deploy an upgrade because the git repo on the server was left with uncommitted local changes to mix.lock. config/config.exs
config/prod.exs
rel/config.exs
deploy.exs
upgrade.exs
|
Okay, here's the complete transcript of my attempt to deploy today, which had the same errors as yesterday. Despite the errors the site actually came up the first time, though when I try to push an update the changes do not get deployed. ON SERVER: rename all relevant files and reboot
ON SERVER: reconnect after reboot, confirm environment vars are correct, install gatling and initialize the repo
ON LOCAL MACHINE: attempt first push. Get error about inability to find .rel file, (same as #39)
BACK ON SERVER : See that _build/prod/rel/tracker/releases directory has not been created. Run gatling.deploy, get error about port being nil
At this point, I discovered to my surprise that the app was actually running and I could load it in browser. On server, inspect the nginx and init.d files that were created
ON SERVER: Inspect the build the that was generated by gatling.deploy
ON LOCAL, I wanted to test deploying a change so I tweaked a couple things and bumped version number. Deploy was rejected because there were uncommitted changes in the git repo.
ON SERVER, see what the uncommitted changes were
ON SERVER: attempt to clean up the deploy with release.clean so I can re-deploy
ON SERVER: reset the git repository so I can push again
ON LOCAL: Push the updated version
BACK ON SERVER: releases dir no longer exists, I guess I misunderstood release.clean :-(
ON SEVER: deploy again to recreate releases directory
I repeated a few iterations of bump version -> push code to try to trigger an upgrade. Each had the same errors as before. Inspecting the build tree to see what the releases look like shows that the .tar.gz file is never created in the numbered release directory. Also in browser I can confirm that none of the tweaks I made in 0.1.3 through 0.1.6 are live, it's still running 0.1.2 on the server.
|
I believe the issue described in #40 is the root cause of this, so closing this one for now. |
It is needed for the seeds to run. Fixes #38.
I'm currently having this issue too. I just pulled down gatling yesterday. The init.d and the nginx files have the same number but the application endpoint says that :port is nil. It looks like the PORT environment isn't being passed into the application startup. |
This fails on the ecto.setup task. I can pass in an arbitrary port number and get past it. |
I have my endpoint config set up as described in the README. When I attempt a deploy, I get an error that the port is nil:
Since the only thing the docs say about the port setting is "Gatling will set this for you automatically" I'm not sure what to look at next. Thanks or any help.
Environment: DigitalOcean server Ubuntu 16.04, nothing else on it but elixir, nginx, and postgresql. I followed the instructions in this blog post as closely as possible.
The text was updated successfully, but these errors were encountered: