I am using one connection library to connect my Elixir shell to ActiveMQ and subscribing to the queues like below and is working well
iex --erl "-pa ebin -env DYLD_LIBRARY_PATH ./priv -env LD_LIBRARY_PATH ./priv -s qpidpn start"
:qpidpn.subscribe('amqp://127.0.0.1/queue://test')
Can someone suggest me, how to create new Elixir Mix application [i mean new module in application: bash script but not from shell] which will do that same thing. That means.
Start of qpidpn first.
Queue subscription to echo messages coming in queue.
Probably the best way would be to use a release for this. Take a look at exrm. Basically, you build the release with mix release, then run your app using rel/qpidpn/bin/qpidpn start. You can then connect to the node using iex with rel/qpidpn/bin/qpidpn remote_console, and queue a subscription with :qpidpn.subscribe('amqp://127.0.0.1/queue://test'). You can then quit the remote shell session, and your app will continue running indefinitely in the background.
Related
When you run a server like MIX_ENV=prod mix phx.server and then on another screen attached to the same server try to run a mix-environment attached iex session like iex -S mix then you get an error and shutdown with a complaint like Failed to start Ranch listener VukWeb.Endpoint.HTTP in :ranch_tcp:listen([port: 4000]) for reason :eaddrinuse (address already in use)
Is there a way to run an iex session while a server is running in a separate screen attached to the same database? I'm confused as to why iex -S mix is even trying to connect to an external port, as that iex session should have no server running nor require an external port simply for loading the mix environment?
I'm aware you can run the server with an iex session like MIX_ENV=prod iex -S mix phx.server, but my understanding is that is neither ideal for performance nor is it nice to have your iex session interrupted by streams of user logs as requests are processed (which is what we're doing right now). I also tried switching up the port like MIX_ENV=prod PORT=4040 iex -S mix but the flag seems to go ignored, as the complaint comes back the same with a reference to port 4000. I'm wonder if maybe there's some hardcoding that's causing the environment variable to be ignored, and if just undoing this hardcoding and switching it to a different port like this is the right approach, even if the port goes unused by the non-server mix environment.
If anyone has a tip on how you can get both a iex session and serving running—or has a different suggestion for workflow that makes such a desire unnecessary—would love to hear!
Thanks
Mix has a perfect very detailed documentation.
Mix.Tasks.Run is a default task. iex -S -mix is essentially equivalent to iex -S mix run.
The latter starts your application, which [wild reasonable guess] in turn starts cowboy as a dependency. Hence the error.
iex -S mix run --no-start
is what you are looking for. This task accepts several arguments, other are listed on the help page I linked.
I am trying to run a Docker image on amazon ECS. I am using a command that starts a shell script to boot up the program:
CMD ["sh","-c", "app/bin/app start; bash"]
in order to start it because for some reason when I run the app (elixir/phoenix app) in the background it was crashing immediately but if I run it in the foreground it is fine. If I run it this way locally, everything works fine but when I try to run it in my cluster, it shuts down. Please help!!
Docker was supposed to keep track of your running foreground process, if the process stop, the container stop. The reason your container work when you use command with "bash" because bash wasn't stop.
I guess you use she'll script to start an application that serve in background like nginx or a daemon. So try to find an option that make the app running foreground will keep your container alive. I.e nginx has an option while starting "daemon off"
for some reason when I run the app (elixir/phoenix app) in the background it was crashing immediately
So you have a corrupted application and you are looking for a kludge to make it looking like it somewhat works. This is not a reliable approach at all.
Instead you should:
make it working in background
use systemctl or upstart to manage restarts of Erlang VM on crashes
Please note that it matters where you have your application compiled. It must be the exactly same architecture/container as the production one, with same Erlang, Elixir, OS versions, otherwise nobody guarantees it will be robust or even working.
I've been trying to debug a phoenix application.
To do so I used the following instructions:
- To set a break point: require IEx; IEx.pry
- To start a debugging server: iex -S mix phx.server
The problem comes when starting the server, the above instruction leads me to the elixir interactive shell (iex(1)>) and does not allow the server to run, from here if I execute the code manually it stops in the prys but I was hopping to have the server running and stop whenever a request hit the pry. Is there any solution?
I am currently using earlang 1.20, elixir 1.5 and phoenix 1.3
It is common behavior that the iex -S mix phx.server command opens an IEx shell. It runs the web server on the port configured for the Phoenix endpoint within the respective MIX_ENV simultaneously to that. For each IEx.pry() breakpoint it executes, it should prompt on the command line whether you want to open an IEx shell there.
Check which MIX_ENV your server is running in, e.g. by typing the following in the IEx shell:
Mix.env
And then find the configuration in the files within the config/ directory. The line should look like this:
config :nameofyourapp, Web.Endpoint,
http: [port: 4000],
Maybe something other than 4000 is configured there? Or maybe some other application, or even a previously started instance of your web application already listens on that port and therefore prohibits the debug server from binding on that port? In that case, shutdown other running mix phx.server processes.
I just started using Ansible and I am having trouble running a server.
I have a server which can be started using java -jar target/server-1.0-SNAPSHOT.jar. However, this will start the server and keep running forever displaying output, so Ansible never finishes.
This is what I tried that never finishes:
- name: Start server
command: chdir=~/server java -jar target/server-1.0-SNAPSHOT.jar
What is the proper way to do this?
Either create a service, as #udondan suggests, or use an asynchronous task to launch your server. http://docs.ansible.com/ansible/playbooks_async.html
As #Petro026 suggested, your choices are asynchronous task or creating a service.
I would strongly suggest against the asynchronous task approach. It's a very fragile solution:
What if the host is restarted?
What if you run your playbook twice?
What if your server app just dies?
Your best bet is to create a service for it, and probably the easiest approach for it would involve using a process control system like supervisord, which is supported by ansible.
From the supervisor docs:
Supervisor is a client/server system that allows its users to monitor
and control a number of processes on UNIX-like operating systems.
Put that in a PID and send the output to nohup.
Something like this:
nohup java -jar target/server-1.0-SNAPSHOT.jar &
In your playbook:
name: Start server
command: chdir=~/server nohup java -jar target/server-1.0-SNAPSHOT.jar &
If you want kill the process kill -9 #numerofpid.
We have a project with different processes, and run it by calling erl -pa ebin, mymodule_supervisor:start_link().
We have set up an ubuntu instance on Amazon EC2. Being new to this, how can we run the project remotely, so we can close the connection and the project will continue to run?
We can run the Erlang shell in the background, but we can't our project on it. It would be perfect to see an example.
Method 1: You could build a release package from your code. If done right, this will embed a complete Erlang system (along with your application and its dependencies) in an easily distributable tar file. Using an automatically generated script the node can then be started as a daemon, running in the background even after you close your shell.
A good way to get started is to use Rebar, which already supports release handling out of the box.
Method 2: Use tmux or screen (both easily installed on Ubuntu) to start your node and detach the session. If you choose tmux, the following should work:
Start tmux simply by running tmux from a shell.
From within tmux, start your node with the erl command as before.
Detach your session using Ctrl-b followed by d. Exit your shell. The node should still be running.
The "proper" way to start the supervisor is to call its start_link function from within the start function of your Erlang application.