ErlCtl 0.3 Released

// December 4th, 2010 // Uncategorized

This is mostly an incremental update, but it does fix a few big issues:

  • Added a verbose mode for debugging use with -v.
  • Fixed a situation where the client hostname was computed but didn't match what the local networking would choose (thus breaking communication in certain environments).
  • Catch more errors in CLI code.

I'd really appreciate it if people can see if this breaks DNS usage on any of their hosts.   It seems solid to me, but I only have so many places to test it out.

You can find it in the usual place.

Thanks!

2 Responses to “ErlCtl 0.3 Released”

  1. pablo says:

    Can you explain how to build and install ErlCtl under ubuntu?

    How does ErlCtl knows how to attach to my app? Don’t I need to start my app with a specific node name?

    Thanks

  2. Pablo,

    Sorry for the extreme delay. Your comment just slipped through the cracks.

    Erlang doesn’t really have a universal deploy / packaging strategy. I’m unclear exactly how it is deployed on Ubuntu. When deploying Erlang using its own tools, you typically create a “release” that bundles up everything in your development environment for deploy. It then generates an archive of the entire system. Regrettably, upstream doesn’t really package things on a more granular level than this. Rebar is a bit more progressive, but I haven’t really torn into how to repackage ErlCtl for rebar.

    To work, the compiled binaries erlctl needs to be in the library path for the system erlang (or the script needs to be modified to run the appropriate erl executable). The easiest way to do this is to put your application and erlctl into the lib directory of the system erlang. Alternatively, you can force the system erlang to find another lib directory by setting the ERL_LIBDIR variable. It’s ugly, but it works.

    ErlCtl will actually start your app for you (or run functions inside of a running app), using the convention app_name@machine.name (with the machine.name determined dynamically if your DNS is correctly configured). Look at the doc/DESIGN.txt file for details.

    Your command implementation is called with knowledge of the current liveness state of the application (i.e. ‘not_running’, ‘running’, etc.). If your command returns the ‘start’ atom when the application is ‘not_running’, the runner script will start it for you as described above.

    I hope that’s somewhat helpful, if terminally late. Best of luck, and feel free to contact me directly via e-mail if you desire additional help.