I have a program that starts the application and then adds (children) workers to a supervisor. Obviously after doing only that it has nothing more left to do and it halts (exits). So making it not halt the VM would allow the workers to work.
The only solution I have came up was to add:
IO.gets "Working... To finish hit <Enter>."
at the end...
I want to build an escript that after running will not halt the Erlang VM just like:
elixir --no-halt -S mix run --eval 'MyApp.CLI.m
ain(["some-arg"])'
or
mix run --no-halt --eval 'MyApp.CLI.m
ain(["some-arg1,some-arg2"])'
Is there a way to do this with escript?
Or should I use a different solution to pack and distribute my program that is actually more like a server/daemon than a command line tool?
A typical approach to packaging such systems is an OTP release. You can use exrm for that.
If for some reasons, you still want to use escript, you can just call :timer.sleep(:infinity) after you start all the applications and processes.
NOTE: Starting from Elixir 1.9
We can use System.no_halt(true) to allow script to never stop.
Here is simple script example:
defmodule Mix.Tasks.NoHalt do
use Mix.Task
def run(_) do
System.no_halt(true)
IO.puts("Never die!")
end
end
Related
I am trying to pass command-line arguments to my elixir release. I have built the release using
MIX_ENV=prod mix release
Now, Am not able to pass any command-line arguments with the start command.
_build/prod/rel/prod/bin/prod start arg1 arg2
Using eval i have achieved passing the arguments but it stops after a while.
_build/prod/rel/prod/bin/prod eval "Hello.nodes([3, :node1])"
Is there any way that I can pass the args through the start flag?
Using eval i have achieved passing the arguments but it stops after a
while.
_build/prod/rel/prod/bin/prod eval "Hello.nodes([3, :node1])"
From the docs:
The eval command starts its own instance of the VM but without
starting any of the applications in the release and without starting
distribution. For example, if you need to do some prep work before
running the actual system, like migrating your database, eval can be a
good fit. Just keep in mind any application you may use during eval
has to be explicitly loaded and/or started.
I'm guessing that your eval tries to use an application that you didn't explicitly load before executing the eval.
Is there any way that I can pass the args through the start flag?
It's not documented, but there are various ways to configure a release:
https://elixir-lang.org/getting-started/mix-otp/config-and-releases.html
Maybe an escript would be a better fit?
escript provides support for running short Erlang programs without
having to compile them first, and an easy way to retrieve the
command-line arguments.
It is possible to bundle escript(s) with an Erlang runtime system to make it self-sufficient and relocatable.
Say I have a simple python script which executes an elixir/erlang script using the subprocess module.
Say the OS PID of the python script is P1 and that of the spawned elixir/erlang script running is P2.
I want to know if communication between P1 and P2 is possible. More specifically, P1 writes something to the stdin of P2, and P2 reads the received input from P1 and writes some corresponding output to its own stdout and P1 reads from the stdout of P2 and again writes something to the stdin of P2 and so on.
I know the other way is possible, i.e., spawning external process from inside elixir/erlang and then communicating with the process. Any help appreciated, thanks.
Yep, this sort of cross-language IPC is entirely possible. The vast majority of the documentation and blog posts and such (and the responses so far here on StackOverflow!) assume the opposite of what you seem to be asking - that is, they assume that Erlang/Elixir is spawning the Python subprocess, rather than Python spawning an Erlang/Elixir subprocess. If that's okay (i.e. you're okay with your Erlang or Elixir app spinning up the Python process), then great! Badu's answer will help you do exactly that, and you could also have a gander at the documentation for Elixir's Port module for an extra reference.
But that doesn't seem to be the answer you seek, and that's less fun. The world needs more documentation on how to go the other way around, so let's dive into the wonderful world of running Erlang as a subprocess of a Python script!
First, our Python script (eip.py):
#!/usr/bin/env python
from subprocess import Popen, PIPE
erl = Popen(['escript', 'eip.escript'],
stdin=PIPE, stdout=PIPE, stderr=PIPE)
ping = input('Ping: ')
outs, errs = erl.communicate(input=ping.encode('utf-8'),
timeout=15)
print(outs.decode('utf-8'))
On the Erlang side (as you might've noticed in that Python code), a really easy way to go about this is to use the escript program, which allows us to write more-or-less self-contained Erlang scripts, like this here eip.escript:
#!/usr/bin/env escript
main(_Args) ->
Ping = io:get_line(""),
io:format("Pong: ~ts", [Ping]).
Now, when you run python3 eip.py and enter asdf at the Ping: prompt, you should get back Pong: asdf.
Doing the same thing with Elixir is only slightly more complicated: we need to create a Mix project with a bit of extra configuration and such to tell Mix to put together an escript file. So let's start with the project:
$ mix new eip
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/eip.ex
* creating test
* creating test/test_helper.exs
* creating test/eip_test.exs
Your Mix project was created successfully.
You can use "mix" to compile it, test it, and more:
cd eip
mix test
Run "mix help" for more commands.
(It's probably overkill to even use Mix for this simple example, but I'm assuming you'll eventually want to do something more advanced than this example)
Next, you'll want to add an escript option to your mix.exs, like so:
defmodule Eip.MixProject do
use Mix.Project
def project, do: [
app: :eip,
version: "0.1.0",
elixir: "~> 1.9",
start_permanent: Mix.env() == :prod,
deps: deps(),
escript: escript()
]
def application, do: [extra_applications: [:logger]]
defp deps, do: []
defp escript, do: [main_module: Eip]
end
And finally, your lib/eip.ex module:
defmodule Eip do
def main(_argv) do
ping = IO.gets("")
IO.puts("Pong: #{ping}")
end
end
And now we just need to build it:
$ mix escript.build
Compiling 1 file (.ex)
Generated eip app
Generated escript eip with MIX_ENV=dev
eip.py will need a slight adjustment to point to this new Elixirified ping/pong IPC thingamabob:
#!/usr/bin/env python
from subprocess import Popen, PIPE, TimeoutExpired
erl = Popen(['escript', 'eip/eip'],
stdin=PIPE, stdout=PIPE, stderr=PIPE)
ping = input('Ping: ')
outs, errs = erl.communicate(input=ping.encode('utf-8'))
print(outs.decode('utf-8'))
Unfortunately, this doesn't entirely work:
$ python3 eip.py
Ping: asdf
Pong: eof
The same results happen even when using a more direct port of the Erlang version (i.e. replacing IO.gets("") with :io.get_line("") and IO.puts("Pong: #{ping}") with :io.fwrite("Pong: ~ts", [ping]), which means something specific to Elixir's STDIN handling in general is causing it to prematurely believe it's reached end-of-file. But hey, at least one direction works!
Like Dogbert said, you can use Ports instead. Check out Erlport
and here is a blog post on communicating between Elixir and Python
I am using rebar for release build of erlang application, when I use start option to start the application it is running fine in background and It returns me the command prompt. I don't want to see all the background output, so I did not run using console option. But If I need any time what is going in background, to check the console due to any error, how do I get that running application's console?
I guess that you have made a release using Rebar and that you have started the node with the generated start script.
So the best way would be to use the start option 'attach':
./bin/mynode attach
It will connect to the shell through pipes so you will be in the actual node that are running so be careful with using Ctrl-c. (add the option "+Bi" to your vm.args file to restrict that..)
You can connect a remote shell to the node, provided it's been set up for distribution. Use the following command:
erl -sname rem -remsh node#host -setcookie the_cookie -hidden
Ctrl-G to enter JCL mode, then 'j' to list, then 'c' followed by a number to connect to the chosen job. See the eshell docs, specifically the JCL section.
Oh, or if by 'command prompt' you mean an OS shell rather than an Erlang shell, IIRC you need to start an Erlang node that is appropriately -name'd or -sname'd (whichever the node you want to connect to uses), then connect to that node ('r' in JCL mode), then connect to the job.
This has been my current routine
sudo nohup erl -sname foo -pa ./ebin -run foo_supervisor shell -noshell -noinput &
where the shell function looks something like this
shell() ->
{ok, Pid} = supervisor:start_link({local,?MODULE}, ?MODULE, _Arg = []),
unlink(Pid).
If I don't unlink from shell it immediately stops for some reason. Is there a way I can just start my application like I would normally ie application:start(foo). Also what if I want to start sasl too? Also where could I learn more about making a self contained package using rebar?
Preface. About your unlink
In this other SO thread #filippo explains why you need the unlink when testing supervisors from the shell.
First. What you need is an Erlang application.
Reading from the doc:
In OTP, application denotes a
component implementing some specific
functionality, that can be started and
stopped as a unit, and which can be
re-used in other systems as well.
Details on how to implement an Erlang application are available here. The three main things you will need to do are:
Have a proper directory structure for your application
Write an application callback module implementing the Erlang application behaviour. That's where you will start your root supervisor
Provide an application resource file. This is where you tell the system - among other things - where to find your application callback module (look at the mod parameter).
Second. Starting SASL.
In the above application resource file, you can specify a list of applications you want to start before your application. You will add something like:
...
{applications, [kernel, stdlib, sasl]},
...
To tell it to start SASL.
Third. Rebar.
There's an introduction to Rebar here, which explains you how to use Rebar to help you in the above steps, to pack your brand new application into an Erlang release and how to start it.
I have erlang application: *.app file and some *.erl files. I compile all of them. In terminal i start erl and there application:start(my_application)., all ok, but if i closed terminal application close too. How can i run application without terminal depending?
Thank you.
You likely want to use the -noshell option to erl. The syntax is
erl -noshell -s Module Function Arguments
So in your case, this might be
erl -noshell -s application start my_application
This should allow you (for example if you are on Unix/Linux) to start your application as a background process and leave it running.
One useful variation is to also call the stop/0 function of the init module so that the Erlang environment will stop when it has finished running your function. This comes in handy if you want to run a simple one-use function and pipe the output to some other process.
So, for example, to pipe to more you could do
erl -noshell -s mymodule myfunction -s init stop | more
Finally, you might also be able to use the escript command to run your Erlang code as scripts rather than compiled code if it makes sense for your situation.
Hope that helps.
The proper way to handle this situation, is building a release containing your app and running the system as so called embedded one.
This release is going to be completely independent (it will hold erts and all the libs like, kernel, std, mnesia etc.).
On start, the new process will not be connected to shell process.
It will be OS process, so you can attach to it with pipes. All script are included in OTP.
Here is some info: http://www.erlang.org/doc/design_principles/release_structure.html
It may seem to be complicated, but tools like rebar do everything for you.