Edeliver will not start the nodes

The only way I can start the deployed release, is to start it manually in the background, like this:

sudo /home/admin/myapp/bin/myapp start

then I can ping the app successfully:

mix edeliver ping production


-----> pinging production servers

production node: 0

  user    : admin
  host    : yy.yy.yy.yy
  path    : /home/admin
  response: pong

production node: 1

  user    : admin
  host    : xx.xx.xx.xx
  path    : /home/admin
  response: pong

However, if I try to start the nodes using edeliver after stopping them with edeliver stop as:

mix edeliver start production

I will get empty response, and the nodes will not start!

Any advice?

1 Like

Do you really have to be root to start the process? Typically you’d have your app’s directory owned by a normal user, and use that user’s identity to start the app. This is the same user you’d put in PRODUCTION_USER in your ./deliver/config file.

Test that user can start the process manually, example if that user on your system is named admin

sudo su admin
/home/admin/myapp/bin/myapp start

I’m guessing that will fail - a likely reason would be if files are owned by root so you may need to chown -R your application directory.

One other thing that may help you is to use the verbose option, e.g.

mix edeliver start production --verbose

Yes, I already set admin as the PRODUCTION_USER in ./deliver/config

If I didn’t add sudo, here is what I get:

07:39:43.275 [error] Failed to start Ranch listener MyApp.Endpoint.HTTP in :ranch_tcp:listen([port: 80, ip: {0, 0, 0, 0}]) for reason :eacces (permission denied)

I am already that user, as whoami will print admin

I also tried verbose switch with mix edeliver start production --verbose I got no details…

1 Like

this means your PRODUCTION_USER is not allowed to open port 80. edeliver executes /home/admin/myapp/bin/myapp start as that user and fails.

you can either allow that user to open port 80 or change the port your app listens on to some higher port, e.g.8080


On Linux only root can open ports below 1024. A typical configuration is to run your app on a higher port, like 4001, and use a webserver like nginx and let it reverse proxy to your app. nginx on any common distribution will be configured to start as root, open port 80 but then setuid so it runs a normal user account. You definitely don’t want a process running as root listening to the internet.

1 Like

Thanks guys, I have fixed the issue by running the app on port 4001, and set the ELB (elastic load balancer) for Amazon to connect to instances at port 4001, very cool :slight_smile:

1 Like