Erlnixify

A system to help Erlang integrate into Unix systems (supporting things like daemontools).

View the Project on GitHub erlware/erlnixify

Erlnixify

Erlang has the problem that it does not integrate nicely with Unix-like systems. It can not be put under things like deamon-tools. You can't trap signals and respond appropriately, etc. This is a small ruby program that serves as a 'front' to an Erlang node. It allows a system like init.d or daemontools to manage Erlnixify and Erlnixify will in-turn manage the Erlang node using standard OTP inputs.

For example, when Erlnixify recieves a SIGTERM signal, it will call init:stop() on the Erlang node. This allows Erlang's release handler to do an orderly shutdown of the Erlang Node.

Erlnixify ensures that the Erlang node is up and running and checks every few seconds (a configurable value) to see if everything is continueing to run correctly. If those checks fail, Erlnixify will shut down the Erlang node and then shut itself down so that whatever is managing the system can restart.

Erlnixify is designed to simply front the Erlang node. It does not provide restarts, log rotation, or anything like that. Those things are expected to be provided by the system (daemontools again).

Erlnixify can be configured from the command line or via a config file. Command line configuration overrides config file configuration. That is, if a configuration value is provided both on the command line and in the config file, the value on the command line is the one that will be used.

** Erlnixify is designed to manage releases. ** ** For self contained releases that do not have Erlang on the system, you must include erl_interface **

Installation

Erlnixify requires ruby 1.9. It does not work on 1.8, but may work on 2.0+ though it has not been tested.

Add this line to your application's Gemfile:

gem 'erlnixify'

And then execute:

$ bundle

Or install it yourself as:

$ gem install erlnixify

Usage

SYNOPSIS

erlnixify [<optional>...] <flags>

EXAMPLE

The following example shows how to run a bare non-otp erlang module. This is not the recommended way to do this at all. You should be using Erlang releases, however it does work and it does illustrate the point.

erlnixify --name example \
          --cookie fubachu \
          --command "erl -setcookie %{cookie} -name %{fullname} -noshell -s my_module start"

The above is enough to get things going with the default values. Running a release might be a bit more complicated. Its more complicated because you are going to want to provide a custom check commands and perhaps custom check intervals.

erlnixify --name example2 \
          --cookiefile /etc/example2/mycookiefile \
          --release /opt/example2 \
          --command '/opt/example2/bin/example2 -setcookie %{cookie} -name=%{fullname} +Ktrue +B -noinput -shutdown_time 5000 +W w' \
          --check "example2 check_status" \
          --checkregex '^ok$' \
          --checkinterval 100

The above assumes we have a viable OTP Release in the /opt/example2 directory. We have placed our cookie in a file in /etc/example2/mycookiefile and we have a script to start our release that lives in the bin directory of the release. We have provided a module example2 with a function check_status that takes no arguments to check the status of the system. If it returns an ok everything is good. We are also going to run that check command every 100 seconds.

We could, of course, have put all the above in a config file as well.

name: example2
cookiefile: /etc/example2/mycookiefile
release: /opt/example2
command: /opt/example2/bin/example2 -setcookie %{cookie} -name=%{fullname} +Ktrue +B -noinput -shutdown_time 5000 +W w
check: example2 check_status
checkregex: ^ok$
checkinterval: 100

Then our Erlnixify could have been much simpler. Assuming our config file was at /etc/example2/erlnixify-config.yaml or Erlnixify command line could have been.

erlnixify --configfile /etc/example2/erlnixify-config

Options

Contributing

See Contributing<