How do I show the absolute path that my Erlang OTP application is loading sys.config from? I.e., if get_all_env (http://erlang.org/doc/apps/kernel/application.html#get_all_env-0) shows unexpected results, how do I see what file is being loaded to debug?
I did this once, so I know it is possible, but sadly I cannot find that code =(
You can use init:get_plain_arguments/0 to get the full list of VM arguments:
(node#localhost)13> init:get_plain_arguments().
["/usr/local/bin/rebar3","shell","--apps","some_app",
"--config","priv/sys.config","--sname","node1#localhost"]
That certainly works if you have started the node manually on CLI. For reference, the output above corresponds to my start script using rebar3:
rebar3 shell --apps some_app --config priv/sys.config --sname node1#localhost
Related
I would like to start two different services in my Docker container and exit the container as soon as one of them exits. I looked at supervisor, but I can't find how to get it to quit as soon as one of the managed applications exits. It tries to restart them up to three times, as is the standard setting and then just sits there doing nothing. Is supervisor able to do this or is there any other tool for this? A bonus would be if there also was a way to let both managed programs write to stdout, tagged with their application name, e.g.:
[Program 1] Some output
[Program 2] Some other output
[Program 1] Output again
Since you asked if there was another tool... we designed and wrote a powerful replacement for supervisord that is designed specifically for Docker. It automatically terminates when all applications quit, as well as has special service settings to control this behavior, plus will redirect stdout with tagged syslog-compatible output lines as well. It's open source, and being used in production.
Here is a quick start for Docker: http://garywiz.github.io/chaperone/guide/chap-docker-simple.html
There is also a complete set of tested base-images which are a good example at: https://github.com/garywiz/chaperone-docker, but these might be overkill and the earlier quickstart may do the trick.
I found solutions to both of my requirements by reading through the docs some more.
Exit supervisord on application exit
This can be achieved by using a custom eventlistener. I had to add the following segment into my supervisord configuration file:
[eventlistener:shutdownevent]
command=/shutdownhandler.sh
events=PROCESS_STATE_EXITED
supervisord will start the referenced script and upon the given event being triggered (PROCESS_STATE_EXITED is triggered after the exit of one of the managed programs and it not restarting automatically) will send a line containing data about the event on the scripts stdin.
The referenced shutdownhandler-script contains:
#!/bin/bash
while :
do
echo -en "READY\n"
read line
kill $(cat /supervisord.pid)
echo -en "RESULT 2\nOK"
done
The script has to indicate being ready by sending "READY\n" on its stdout, after which it may receive an event data line on its stdin. For my use case upon receival of a line (meaning one of the managed programs has exited), a SIGTERM is sent to the supervisord process being found by the pid it leaves in its pid file (situated in the root directory by default). For technical completeness, I also included a positive answer for the eventlistener, though that one should never matter.
Tagged output on stdout
I did this by simply starting a tail process in the background before starting supervisord, tailing the programs output log and piping the lines through ts (from the moreutils package) to prepend a tag to it. This way it shows up via docker logs with an easy way to see which program actually wrote the line.
tail -fn0 /var/log/supervisor/program1.log | ts '[Program 1]' &
Hi I have a command which starts an Erlang node (using run_erl program) and then I connect to it using to_erl program.
After connecting to the node I issue the following command to get the home dir.
init:get_argument(home).
And it returns "/" as the home directory, which I know it is definitely wrong.
What is the reason for this?
I do not know how you setup is so it is hard to analyse but the init:get_argument(home) call will return the value of the environment variable HOME (on any form of unix and it can be inspected by calling echo $HOME).
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.
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.
I recently installed Erlang RFC4627 (JSON-RPC) with the debian package. I ran the test server using:
sudo erl -pa ebin
and then at the prompt:
test_jsonrpc:start_httpd().
returned
ok
I tested with http://:5671/ and got the success messages.
When I try to run rabbitmq-http2 however, I get the errors that the readme says are caused by rfc4627's code not being on the erlang search path. How do I put it on the path. I saw something on Dave Thomas's blog which suggested putting the path in the file:
~/.erlang
This didn't seem to work for me (maybe I did it wrong?).
The code module is how you manipulate the path within an application.
The flags -pa that you used in starting the Erlang shell actually refer to a function in this module:
add_patha(Dir) -> true | {error, What}
You are right about the .erlang file in your home directory - it is run at start-up time of the shell and you can add in handy paths.
For an application you can start the shell with a batch file that calls something like this:
erl -pa ./ebin ../../lib/some/path/ebin
The flags behaviour of erl is described here.
For more sophisticated path management you need to get familiar with how OTP release management is done (but I suspect that is a while away for you yet).