Starting a standalone Elixir runtime fails on Windows 10 #194
Comments
|
@juhalehtonen thanks for reporting! What happens if you do this inside IEx on Windows? |
|
|
Just for sake of sanity, I tested the same scenario under WSL2. Starting the standalone runtime worked perfectly there. |
|
@juhalehtonen what about this? If that also works, can you please put an IO.inspect here? https://github.com/elixir-nx/livebook/blob/main/lib/livebook/runtime/elixir_standalone.ex#L56 - then copy the args and pass that to System.cmd? |
This seems to return just: iex(livebook_zghjge7f@2080-OMG)3> eval = "(\n init_ref = make_ref()\n parent_process = {:livebook_parent_process_name_ek5c2dts, :\"livebook_j35nq3mw@2080-OMG\"}\n send(parent_process, {:node_started, init_ref, node(), self()})\n receive do\n {:node_initialized, ^init_ref} ->\n manager_ref = Process.monitor(Livebook.Runtime.ErlDist.Manager)\n receive do\n {:DOWN, ^manager_ref, :process, _object, _reason} ->\n :ok\n end\n after\n 10000 ->\n :timeout\n end\n)"
"(\n init_ref = make_ref()\n parent_process = {:livebook_parent_process_name_ek5c2dts, :\"livebook_j35nq3mw@2080-OMG\"}\n send(parent_process, {:node_started, init_ref, node(), self()})\n receive do\n {:node_initialized, ^init_ref} ->\n manager_ref = Process.monitor(Livebook.Runtime.ErlDist.Manager)\n receive do\n {:DOWN, ^manager_ref, :process, _object, _reason} ->\n :ok\n end\n after\n 10000 ->\n :timeout\n end\n)"
iex(livebook_zghjge7f@2080-OMG)4> System.cmd(System.find_executable("elixir"), ["-e", eval])
{"", 0}
The existing Port.open does seem to return a Port when piped through IO.inspect:
What I did here was: Assuming I got the call right, the System.cmd variant seems to be returning the following: |
|
Thanks a lot! So if it is not the eval, one of the And then I would try calling the executable multiple times, removing the flags, until we find the problematic one. :) |
|
Thanks José! I tried fiddling with the different flags for a while, but no change in the flags passed seemed to make a difference. I'll get back to this more properly once I find the time, as Windows isn't quite my go-to :) I started to wonder if this has something to do with the Windows-related issues brought up in https://elixirforum.com/t/port-open-eacces-on-windows/5442 , although they don't quite seem to match either. |
|
@juhalehtonen thank you for the help so far!
Do you mean they all succeed? FWIW, System.cmd simply calls spawn_executable too, so I don't think the issue is with ports... but maybe we are missing some flags. |
|
@juhalehtonen can you try removing the |
I tried removing the nouse_stdio flag, but that didn't make a difference. I also went through I also tried to use the |
|
Thanks for the report! This is crazy. :D Just to be clear, can you please try this: That will inspect all options. Then go to And then if it works, please call If you want to do a pairing session, let me know and I am definitely game. :) |
|
I replaced defp start_elixir_node(elixir_path, node_name, eval) do
# Here we create a port to start the system process in a non-blocking way.
Port.open({:spawn_executable, elixir_path}, [
:binary,
:nouse_stdio,
:hide,
args: elixir_flags(node_name) ++ ["--eval", eval]
] |> IO.inspect(limit: :infinity))
endand then tried starting the runtime again. Note that here I had reverted any previous changes, using the latest from master sans the function change above: Removing the There has to be something very Windows-specific that's being missed here. Probably something very obvious-in-hindsight too :).
I'm open to having a look at this together as well. |
|
I am sending you an email. :D |
|
Here is a minimal example that isolates that invocation and we can run on IEx without Livebook: then Process.register(self(), :hello)
port = Port.open(
{:spawn_executable, System.find_executable("elixir")},
[
:binary,
:nouse_stdio,
:hide,
{:args,
["--sname", "prefix-#{node()}", "--erl",
"+sbwt none +sbwtdcpu none +sbwtdio none -elixir ansi_enabled true",
"--hidden", "--cookie", Atom.to_string(Node.get_cookie()), "--eval",
"(\n init_ref = make_ref()\n parent_process = {:hello, :\"#{node()}\"}\n send(parent_process, {:node_started, init_ref, node(), self()})\n receive do\n {:node_initialized, ^init_ref} ->\n :ok\n after\n 10000 -> :timeout\n end\n)"]}
]
)
Port.monitor(port)
flush() |
1. Do not use nouse_stdio as it causes slowdowns when IEx is also running 2. Reduce the amount of generated random atoms by using the child_node as the name of the parent process 3. Do not pass quoted strings to Windows to eval, use argv instead Closes #194.
|
@juhalehtonen, thank you so much for the pairing session! ❤️ 🙌 I have sent #201 that should address the issue, can you please try it out? We found out the issue was due to the differences on how Unix and Windows handle escaped strings. The solution I found was to pass the injected parameters as argv instead of "interpolating" them. |
|
Thanks José! Unfortunately the underlying issue still seems to persist: |
|
Oh noes, can you do another pairing session later on? |
|
In any case, can you try inspecting System.argv() here? Then call |
|
And here is an updated version that isolates it: Process.register(self(), :"hello-#{node()}")
port = Port.open(
{:spawn_executable, System.find_executable("elixir")},
[
:binary,
:hide,
{:args,
["--sname", "hello-#{node()}", "--erl",
"+sbwt none +sbwtdcpu none +sbwtdio none -elixir ansi_enabled true",
"--hidden", "--cookie", Atom.to_string(Node.get_cookie()), "--eval",
"(\n [parent_node] = System.argv()\n init_ref = make_ref()\n parent_process = {node(), String.to_atom(parent_node)}\n send(parent_process, {:node_started, init_ref, node(), self()})\n receive do\n {:node_initialized, ^init_ref} ->\n :ok\n after\n 10000 -> :timeout\n end\n)",
"--",
Atom.to_string(node())]}
]
)
Port.monitor(port)
flush() |
Running the isolated code gives us
I have some free time during the next two hours or so, if that works for you :) |
|
@juhalehtonen sounds good, i will be waiting on the same place! |
1. Do not use nouse_stdio as it causes slowdowns when IEx
is also running
2. Reduce the amount of generated random atoms by using the
child_node as the name of the parent process
3. Do not pass quoted strings nor newlines to Windows to eval,
use argv instead
Closes #194.
|
The second issue was around newlines but it is addressed now. Thank you @juhalehtonen <3 and Windows should be good to go @samaaron! |
|
This issue seems back again:
|
As stated in the title, starting a standalone Elixir runtime / node seems to fail on Windows 10. When attempting to click on the "Connect" button in the Liveview UI, the following error comes up in the terminal:
The same behaviour can be encountered when calling
Livebook.Runtime.ElixirStandalone.init()directly via iex. The process managing the startup of the node seems to immediately return with :DOWN, so something seems to be going wrong in the startup there.What does work for me on my Windows 10 system is manually starting an "attached node" via
iex --sname test.For the sake of further debugging, I've called
IO.inspect([elixir_path: elixir_path, node_name: node_name, eval: eval])within theLivebook.Runtime.ElixirStandalone.start_elixir_nodefunction when clicking the connect button. The results, as seen in the Windows 10 command prompt, are as follows:Perhaps the issue is caused by a Windows security policy that prevents certain things from being run here? I don't normally use Windows as my development environment, so I might be way off with my reasoning here.
The text was updated successfully, but these errors were encountered: