Elixir 1.9 release daemon vs daemon_iex

Elixir 1.9’s mix release provide two ways to start beam in background, daemon and daemon_iex. As far as I know, both will start beam in background, and daemon_iex will also start iex in background, but you cannot interactive with that. You still need to use remote to start another beam and connect to it to interact with it. So what’s the point of daemon_iex? Or am I missing anything here?

Both daemon options can be interacted with using the to_erl executable and pointing it to tmp/pipe/ (trailing / is important):

$ mix release
$ cd _build/dev/rel/my_app
$ bin/my_app daemon_iex
$ to_erl /tmp/pipe/

More information in the docs: https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-daemon-mode-unix-like

3 Likes

Here’s a (incomplete) comparison between elixir 1.9 and distillery.

    +------------+----------------+
    | elixir1.9  | 1.8+distillery |
    +------------+----------------+
    | start      | foreground     |
    | start_iex  | console        |
    | daemon     | n/a            |
    | daemon_iex | start          |
    | remote     | remote_console |
    | stop       | stop           |
    | pid        | pid            |
    | n/a        | ping           |
    | n/a        | attach         |
    +------------+----------------+

So the reason that attach is removed is mainly because when people attach to a background beam, it’s easy to kill the beam by accident if they didn’t use ctrl-d to detach.

So the daemon_iex is same as distillery’s start, where you can attach to the beam with iex. If we use daemon, then we can only interact with the background beam by remote to it. Even if we use to_erl to attach to it, we are unable to interact with it since iex is not started.

I think it’s worth mention the difference in the doc. Because it’s kinda confusing on what daemon_iex is do, and I guess most people don’t know what run_erl or to_erl does, since we rarely use them directly.

14 Likes

When I started app as daemon_iex commands stop, pid and remote not working with error
Could not contact remote node release@my-app, reason: :nodedown. Aborting...
But node release@my-app up and working.

Same issue for me, running on render.com. Did you find a solution to this @Merff?

EDIT: In my case, it was that I was starting the server with MIX_ENV=prod mix phx.server instead of _build/prod/rel/my_app/bin/my_app start

@Merff @noisykeyboard

If you modify the epmd port, you need to specify it.

ELIXIR_ERL_OPTIONS="-epmd_port 12345" RELEASE_DISTRIBUTION=name RELEASE_NODE=name@exaple.com RELEASE_COOKIE=secret _build/prod/rel/my_app/bin/my_app stop

The specific reason is because the start command loads the vm.args file, while rpc does not.

You can open _build/prod/rel/my_app/bin/my_app to see the specific implementation

case $1 i
  start)
    start "elixir" --no-halt
    ;;

  restart|stop)
    rpc "System.$1"
    ;;

// ...

rpc () {
  exec "$REL_VSN_DIR/elixir" \
       --hidden --cookie "$RELEASE_COOKIE" \
       --$RELEASE_DISTRIBUTION "rpc-$(rand)-$RELEASE_NODE" \
       --boot "$REL_VSN_DIR/$RELEASE_BOOT_SCRIPT_CLEAN" \
       --boot-var RELEASE_LIB "$RELEASE_ROOT/lib" \
       --rpc-eval "$RELEASE_NODE" "$1"
}

start () {
  export_release_sys_config
  REL_EXEC="$1"
  shift
  exec "$REL_VSN_DIR/$REL_EXEC" \
       --cookie "$RELEASE_COOKIE" \
       --$RELEASE_DISTRIBUTION "$RELEASE_NODE" \
       --erl "-mode $RELEASE_MODE" \
       --erl-config "$RELEASE_SYS_CONFIG" \
       --boot "$REL_VSN_DIR/$RELEASE_BOOT_SCRIPT" \
       --boot-var RELEASE_LIB "$RELEASE_ROOT/lib" \
       --vm-args "$RELEASE_VM_ARGS" "$@"
}
1 Like