Exrm release upgrade (hot code swapping) not working in windows

In my efforts to get UPGRADE working (for a Phoenix application) for exrm releases on Microsoft Windows, I noticed that I could not ping the node, even though it was running. So I checked and it was using nonde@nohost.

To solve this, I called these functions from the main application module:

:net_kernel.start([name, :longnames])
:erlang.set_cookie(node(), cookie)

This works (at least it starts the node properly), but its not a proper solution.

erlsrv is being passed the node name by the application release bat file, but it seems that its not being set when the application is actually started.

I approached this initially thinking I needed to get this working quickly for operational purposes, but now want to do it properly by patching something in erlsrv.c or in the batch files.

For your information, the following code is how I got my application working:

  use Application

  @version Mix.Project.config[:version]
  def version(), do: @version

  @env Mix.env
  def env(), do: @env

  defp start_network(name, cookie) when is_atom(name) do
    case :net_kernel.start([name, :longnames]) do
      {:ok, pid} -> :erlang.set_cookie(node(), cookie)
      {:error, {{:already_started, pid}, _}} -> :already_started
    end
  end

  defp get_vm_args() do
    {:ok, data} = File.read(Path.expand("../../releases/#{version()}/vm.args", System.cwd!()))
  end

  defp get_node_name(data) do
    case Regex.run(~r/-name ([^\n]+)/, data) do
      nil -> nil
      [_, name] -> String.to_atom(name)
    end
  end

  defp get_cookie(data) do
    case Regex.run(~r/-setcookie ([^\n]+)/, data) do
      nil -> nil
      [_, cookie] -> String.to_atom(cookie)
    end
  end

  def start(_type, _args) do
    import Supervisor.Spec

    if node() == :nonode@nohost and env() == :prod do
      data = get_vm_args()
      node_name = get_node_name(data)
      cookie = get_cookie(data)
      start_network(node_name, cookie)
    end

… followed by the normal supervision startup stuff.

I will be deleting this code once I get erlsrv.c patched, so I’m not really posting this asking for advice about how to do it in Elixir, this is to illustrate what I needed to do, i.e. what erlsvr.c is not doing now. I’m posting here, hoping for help regarding erlsvr.c and the batch files

Thanks

I noticed that the install_upgrade.escript in exrm, called also from relx needs to be passed a first parameter of “install”. This also needs to be fixed, otherwise the upgrade still does not work.

      {:relx, github: "bmodra/relx", override: true},
      {:exrm, github: "bmodra/exrm", override: true},

… I am working on some changes … The changes to my forks above work for upgrade.
Next I will work on the start/install scripts and possibly erlsrv.c

boot.bat (in exrm) was initialising conform_opts to "", as if that was an empty string, but in a bat file its not:

@set conform_opts=""

This code was failing:

:install
@if "" == "%2" (
  :: Install the service
  set args=%erl_opts% %conform_opts% -setcookie %cookie% ++ -rootdir \"%rootdir%\"
  set svc_machine=%erts_dir%\bin\start_erl.exe
  set description=Erlang node %node_name% in %rootdir%
  %erlsrv% add %service_name% %node_type% "%node_name%" -c "%description%" ^
            -w "%rootdir%" -m "%svc_machine%" -args "%args%" ^
            -stopaction "init:stop()."

The args string had "" before the rest of the arguments (e.g. -setcookie…) whch caused them to be removed (due to how batch file arguments get expanded)
So I changed the initialisation to:

@set conform_opts=

https://github.com/bitwalker/exrm/pull/406
https://github.com/erlware/relx/pull/593

1 Like

I run substantially changed exrm windows bat files that I’ve edited over time… Never committed them back since exrm was being replaced by distillary (does it have Windows support yet?). A lot of those changes look very familiar, including others I have… ^.^;

Just chiming in to say that yes, Distillery has windows support now :). If you wouldn’t mind taking a look at the new batch scripts and giving them a review, it would be much appreciated!

WHOO! We are in a crunch period at work currently but I will do that before the next deployment and report any issues found. :slight_smile: