I've created a simple erlang release using rebar, following this tutorial: http://www.metabrew.com/article/erlang-rebar-tutorial-generating-releases-upgrades
I can install and start the dummynode by going to the dummynode/bin folder and running:
dummynode install
dummynode start
In the vm.args file, I've set the node name to dummynode#192.168.1.129
When I start another node with:
erl -name cole#192.168.1.129 -setcookie dummynode
I can then launch the erlang observer. In the "Nodes" menu, I see that the dummynode node is listed, but when I try to connect, observer crashes.
I can't make heads or tails of the crash dump file, but it seems like erlang is complaining about distribution not being enabled.
I cannot connect the nodes with net_adm:ping/1 and can't figure out why observer was able to at least see the detached dummynode node.
Can anyone explain how I can connect to the dummynode node?
UPDATE: I've confirmed that the cookies are the same on both nodes. Also, AFAICT rebar is packaging observer and all of it's dependencies into the release.
If you cannot connect with net_adm:ping/1 check that both nodes have the same cookie (erlang:get_cookie/0).
The 2 nodes must have the same cookie to form a distributed system, but observer can show you at least all the nodes that are present on your machine, even if they have not the samme cookie.
Observer needs some modules installed on remote node to run. It crashes silently if they are not presented there. I don't remember which ones it was so you have to experiment so add some application requirements to your target distribution.
Mystery solved! It was neither a cookie nor dependency issue. The generated vm.args file has a line:
-name dummynode#127.0.0.1
Which you'd think would mean that if I change the node name to something like
-name mynode#mydomain.com
then rebar would start the runtime with the flag:
erl -name mynode#mydomain.com
This is not the case. It turns out that rebar always invokes the runtime (at least on windows) with the -sname flag, even if you adjust the node name. If you want to distribute your cluster across physical machines (using long names with the -name flag) you need to edit the generated bin\dummynode.cmd file, and change all of the -sname flags to -name.
I've filed an issue with the rebar team, but I don't know if they consider this to be a bug or not.
Related
Im deploy phx app using docker, running --remsh command from within the same container.
But it return could not contact remote node.
Anybody know the solution ?
Here is the snapshot
You seem to start the application as :nonode#nohost. To connect to it, you should have it started with either a short or fully qualified name.
mix release.init creates rel folder with two template files in it. Check env.sh.eex and make sure you start a release with a short name given. This should work:
export RELEASE_DISTRIBUTION=sname
export RELEASE_NODE=<%= #release.name %>
Sidenote: please post everything as plain text, not as images.
There is a problem in your command, please use --cookie instead of -cookie
I have googled for three hours but to no avail.
I have an ejabberd installation which is not installed using apt. It is installed from source and there is no program called ejabberd in it. Start and Stop and everything is through ejabberdctl.
It was running perfectly for a month and all of a sudden one day it stopped with the infamous
kernel pid terminated error
Anytime i do
sudo ejabberdctl start --node ejabberd#MasterService
A erl_crash file gets generated and when i try
ejabberdctl
i get
Failed to connect to RPC at node ejabberd#MasterService
Now what have i tried
Tried killing all running process of ejabberd, beam, epmd and starting fresh - DID NOT WORK
Checked /etc/hosts and hostname and all is well. Hostname is provided in hosts file with the IP
Checked the ejabberdctl.conf file to ensure teh host name is indeed right and the node name is right
checked .erlange.cookie file is being created with content in it
In all of web one way or another the search led me to either one of the above.
I have nowhere else to go and dont know where else to look. Any help would be much appreciated.
You'll have to analyze the crash dump to try to guess why it failed.
To carry out this task, Erlang has a special webtool (called, uh, webtool) from which a special application — Crash Dump Viewer — might be used to load a dump and inspect the stack traces of the Erlang processes at the time of the crash.
You have to
Install the necessary packages:
# apt-get install erlang-webtool erlang-observer
Start an Erlang interpreter:
$ erl
(Further actions are taken there.)
Run the webtool. In a simplest case, it will listen on the local host:
webtool:start().
(Notice the period.) It will print back an URL to navigate in your browser to reach the running tool.
If this happens on a server, and you'd rather like to have the webtool listen on some non-local-host interface, the call encantation would be trickier:
webtool:start(standard_path, [{port, 8888}, {bind_address, {0, 0, 0, 0}}, {server_name, "server.example.com"}]).
The {0, 0, 0, 0} IP spec will make it listen everywhere, and you might as well specify some more sensible octets, like {192, 168, 0, 1}. The server_name clause might use arbitrary name — this is what will be printed in the generated URL, the server's hostname.
Now connect to the tool with your browser, navigate to the "Start tools" menu entry, start crash dump viewer and make a link to it appear in the tool's top menu. Proceed there and find a link to load the crash dump.
After loading a crash dump try to mess around with the tool's interface to look at the stack traces of the active Erlang processes. At least one of them should contain something fishy, which should include an error message — that's what you're looking after to refine your question (or ask another at the ejabberd mailing list).
To quit the tool, run
webtool:stop().
in the running Erlang interpreter. And then quit it either by running
q().
and waiting a bit or pressing Ctrl-g and then entering the letter q followed by pressing the Return key.
The relevant links are: the crash dump viewer manual and the webtool manual.
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 am trying to contribute more with couchdb code, but I have really no idea how it is done the right way.
I have cloned the source from apache git repository and built it with
./configure
make && sudo make install
Then I wanted to change a file from the source called couch_httpd_show.erl
Do I need to run make && sudo make install again for every change I make to the source code and want to see how it behaves?
I am sure there's a more practical way to do it, because this approach is a bit time and patience consuming right?
Yes, there is a shortcut.
./configure
make dev
./utils/run
This builds and runs CouchDB entirely in the current directory. Instead of running as a background daemon, CouchDB will run in the foreground and output log messages to the terminal. It uses some local directories to store stuff: ./tmp/log for logs, ./tmp/lib for databases, and (if I remember correctly) ./etc/couch/local_dev.ini for configuration.
If you run this instead:
./utils/run -i
then you will also have an interactive Erlang prompt, which you can use to help debug.
When I work on CouchDB, I run this in the shell:
make dev && ./utils/run -i
After I change some code, I press ^C, up-arrow, return.
When I joined Couchio, I was responsible for production CouchDB deployments. I asked Chris Anderson for advice about something and he said, "Sorry, ask Jan. I've been just using utils/run for years!"
You can rebuild that one file and drop the output beam in place and restart.
erlc <file.erl>
& then copy the .beam file into place. To restart couchdb use either init:restart(). in the erlang shell or POST /_restart to CouchDB.
Although you might want to consider using the commandline erlang & javascript test suite also to ensure you didn't break anything.
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.