Unable to run erlexec in a escript

Questions / Help
,
1

I’m trying to run erlexec in an escript. It seems like it should be possible, but since erlexec depends on a priv directory by default, (which isn’t supported by escripts) I just need to configure it to point to a different port executable. I should be able to pass a {:portexe, executable_path option, but I’m not sure where to put that configuration because the startup of erlexec happens automatically on since on application boot by Elixir.

Here’s a test repository: https://github.com/axelson/erlexec_escript_example
Just run:

mix deps.get
mix escript.build
./erl_exec_test

And you should see an error message like:

22:15:12.827 [warn]  Priv directory not available

22:15:12.834 [info]  Application erlexec exited: :exec_app.start(:normal, []) returned an error: shutdown: failed to start child: :exec
    ** (EXIT) bad return value: 'Cannot find file : no such file or directory'
Could not start application erlexec: :exec_app.start(:normal, []) returned an error: shutdown: failed to start child: :exec
    ** (EXIT) bad return value: 'Cannot find file : no such file or directory'

Relevant links:

Can anyone point me in the right direction?

2

My suggestion would be to include the binary inside the escript (you can read it, put it in a module attribute and put it in a function) and then write it down to the user temporary directory. You can delay the start of erlexec by setting it to runtime: false in your mix.exs.

2 Likes
3

Thanks that sounds like it’ll work. Setting it to runtime: false will let me control the startup of the dependency manually and then it should be pretty straightforward to adjust the :portexe setting.

4

Okay, based on your instructions I’ve created a little helper module that copies the exec-port binary into the systems temp folder and it is currently working well:

defmodule ErlexecInit do
  @moduledoc """
  Responsible for starting Erlexec in a manner compatible with escripts. By
  default the exec-port binary is compiled into erlexec's priv folder, but since
  escripts don't have access to the priv directories we need to store the binary
  into the code and then on startup we need to write it out into the system's
  tempdirectory

  Reference: https://elixirforum.com/t/unable-to-run-erlexec-in-a-escript/21603
  """

  use GenServer

  @exec_port_binary_path Application.app_dir(:erlexec, [
                           "priv",
                           :erlang.system_info(:system_architecture),
                           "exec-port"
                         ])

  @execport_binary File.read!(@exec_port_binary_path)

  def start_link(_, name \\ __MODULE__) do
    GenServer.start_link(__MODULE__, nil, name: name)
  end

  @impl GenServer
  def init(_) do
    port_exe_path =
      System.tmp_dir!()
      |> Path.join("tmp-exec-port-#{System.unique_integer([:positive])}")
      |> String.to_charlist()

    File.write!(port_exe_path, @execport_binary)
    File.chmod!(port_exe_path, 0o700)

    :exec.start(portexe: port_exe_path)

    {:ok, []}
  end
end
3 Likes
5

I ran into the same issue.

I understand I can defer the startup of erlexec by using runtime: false, and I understand how you are extracting the binary into the local file system.

However it isn’t clear to me how I am supposed to configure erlexec at runtime to use the extracted portexe. Could someone please assist me with this part?

I have tried using application.set_env functions, but I don’t think that is the right place to be looking?

6

I haven’t looked at this code in a while but I think you’re referring to this part of the snippet above:

:exec.start(portexe: port_exe_path)

I’m calling that function in a GenServer that is part of my supervision tree but you would likely also be okay if you dropped that code directly into your application.ex file in the start/2 function.

Here’s the full code if you want to take a look ls_proxy/ls_proxy/lib/erlexec_init.ex at 2435d956f924813021493a9b292f81b81a7eb00d · axelson/ls_proxy · GitHub

1 Like
7

axelson, thanks for your quick response.

That did indeed work, I misunderstood the purpose of that line of code, but it makes sense now.

Best Regards,

1 Like