Can't start application on windows 10
jsayegh opened this issue · 15 comments
Steps to reproduce
-
set MIX_ENV=prod
-
mix release
-
Try to call _build\prod\rel\APPNAME\bin\YOURAPPNAME.bat foreground
{"init terminating in do_boot",{load_failed,[LIST OF MODULES]}}
init terminating in do_boot ({load_failed, ...
Crash dump is being written to: erl_crash.dump...done
Description of issue
-
What are the expected results?
The app should run. -
What version of Distillery?
version: "2.0.12" -
What OS, Erlang/Elixir versions are you seeing this issue on?
Erlang/OTP 21 [erts-10.1] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] Elixir 1.7.4 (compiled with Erlang/OTP 19) -
If possible, also provide your
rel/config.exs, as it is often
my first troubleshooting question, and you'll save us both time :)
# Import all plugins from `rel/plugins`
# They can then be used by adding `plugin MyPlugin` to
# either an environment, or release definition, where
# `MyPlugin` is the name of the plugin module.
~w(rel plugins *.exs)
|> Path.join()
|> Path.wildcard()
|> Enum.map(&Code.eval_file(&1))
use Mix.Releases.Config,
# This sets the default release built by `mix release`
default_release: :default,
# This sets the default environment used by `mix release`
default_environment: Mix.env()
# For a full list of config options for both releases
# and environments, visit https://hexdocs.pm/distillery/config/distillery.html
# You may define one or more environments in this file,
# an environment's settings will override those of a release
# when building in that environment, this combination of release
# and environment configuration is called a profile
environment :dev do
# If you are running Phoenix, you should make sure that
# server: true is set and the code reloader is disabled,
# even in dev mode.
# It is recommended that you build with MIX_ENV=prod and pass
# the --env flag to Distillery explicitly if you want to use
# dev mode.
set dev_mode: true
set include_erts: false
set cookie: :"vw;sOrsaeMy$Ebtbj}>B?Id*!O`rwJGPc[sBGJr!2?ThESsT.3fKi(NlxnB8}&?t"
end
environment :prod do
set include_erts: true
set include_src: false
set cookie: :"0/booC|*Q*v_WW8>iHi:F$A9rBZY61Vi1s)CB:6aVUJ*Dtth^qD=B(!l@N>3fa[["
set vm_args: "rel/vm.args"
end
# You may define one or more releases in this file.
# If you have not set a default release, or selected one
# when running `mix release`, the first release in the file
# will be used by default
release :myapp do
set version: current_version(:myapp)
set applications: [
:runtime_tools
]
end
Creating a release for Windows is quite a nightmare. Having similar issues. I was getting the above, but now it just hangs completely.
Running in console I see:
Directory: C:\Users\l_m_s\Documents\APP\_build\prod\rel
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/01/2019 13:16 var
Set-Content : A parameter cannot be found that matches parameter name 'InputObject'.
At
C:\Users\l_m_s\Documents\app\_build\prod\rel\MYAPP\releases\MYAPP.ps1:103
char:77
+ ... -path $Env:RELEASE_MUTABLE_DIR "WARNING_README") -InputObject $warnin ...
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-Content], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.SetContentCommand
Directory: C:\Users\l_m_s\Documents\app\_build\prod\rel\var
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/01/2019 13:16 log
@Lazarus404 the problem you've mentioned has been solved with this commit: c42a47d
The problem is, if I use branch master, the release hangs completely, with no error message.
Actually, I do eventually get an error
Directory: C:\Users\l_m_s\Documents\app\_build\prod\rel
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/01/2019 13:28 var
Directory: C:\Users\l_m_s\Documents\app\_build\prod\rel\var
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 07/01/2019 13:28 log
The script failed due to call depth overflow.
+ CategoryInfo : InvalidOperation: (0:Int32) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CallDepthOverflow
Okay, so, the reason it hangs is because of this function in libexec\win\erts.ps1
function WhereIs-Erts-Bin() {
if (($Env:ERTS_VSN -eq $null) -or ($Env:ERTS_VSN -eq "")) {
get-command erl | select-object -ExpandProperty Definition
} elseif (($Env:USE_HOST_ERTS -eq $null) -or ($Env:USE_HOST_ERTS -eq "")) {
$erts_dir = (join-path $Env:RELEASE_ROOT_DIR ("erts-{0}" -f $Env:ERTS_VSN))
if (test-path $erts_dir -PathType Container) {
join-path $erts_dir bin
} else {
$Env:ERTS_DIR = ""
whereis-erts-bin
}
} else {
$Env:ERTS_DIR = ""
whereis-erts-bin
}
}
The function goes into an endless loop when it can't find erts. Commenting out the recurring calls allows the script to exit out with Error occurred! Erlang runtime not found. If Erlang is installed, ensure it is in your PATH.
The weird thing is that erts is included in the release alongside the releases folder. I'll do some digging and figure out why it can't find it.
@Lazarus404 Try removing the erts.ini file inside erts folder. This is another change I made with the commit I linked above. Let us know...
No, it's not that. I figured it out. Somewhere, %RELEASE_ROOT_DIR% is being set AFTER it's set in the batch file. It's correct in the batch file, but when used in the query above, it looks for erts in _build\prod\rel instead of _build\prod\rel\my_app
Setting a secondary env var in the batch file and using that in the erts search function above fixes it, but that's not the fix. Where is %RELEASE_ROOT_DIR% being modified?
Okay, so, it's being re-set in several places, including the release apps own ps1 file :) Not so clean.
Just to be clear, are you all using PS Core to run the release? If you are using an older version of Powershell, the scripts may not be compatible. The powershell scripts in Distillery currently all require PS Core.
So, I've had to revisit this to see if I can fix it. I've set a secondary env var in the batch file (saves rewriting everything) and using that same env var in place of RELEASE_ROOT_DIR. The bit I can't seem to fix, though, is:
$output = erl -noshell -eval "io:format(\`"~s~n~s~n\`", [code:root_dir(), erlang:system_info(version)])." -s erlang halt
This returns
=CRASH REPORT==== 12-Mar-2019::17:12:28.003000 ===
crasher:
initial call: application_master:init/4
pid: <0.73.0>
registered_name: []
exception exit: {bad_return,
{{elixir,start,[normal,[]]},
{'EXIT',
{undef,
[{elixir,start,[normal,[]],[]},
{application_master,start_it_old,4,
[{file,"application_master.erl"},
{line,277}]}]}}}}
in function application_master:init/4 (application_master.erl, line 138)
ancestors: [<0.72.0>]
message_queue_len: 1
messages: [{'EXIT',<0.74.0>,normal}]
links: [<0.72.0>,<0.42.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 987
stack_size: 27
reductions: 197
neighbours:
=INFO REPORT==== 12-Mar-2019::17:12:28.065000 ===
application: elixir
exited: {bad_return,
{{elixir,start,[normal,[]]},
{'EXIT',
{undef,
[{elixir,start,[normal,[]],[]},
{application_master,start_it_old,4,
[{file,"application_master.erl"},
{line,277}]}]}}}}
type: permanent
Executing the evaluated line directly in the console results in the correct output, so I'm not sure why this is happening.
@bitwalker I can now run the app in console mode, but if I run with start, I get unrecognized option "ERTS_LIB_DIR"
I have PowerShell Core 6 installed and running on the server. Is there anything else you can think of that i might need to install or configure?
@Lazarus404 ERTS_LIB_DIR is usually set via -boot_var ERTS_LIB_DIR "some/path" in the various scripts, this is a flag for erl specifically. If you are getting an unrecognized option error like that, I think it means something is wrong with the command line arguments being passed (i.e. -boot_var is missing probably, or for some reason ERTS_LIB_DIR is being treated as its own option)
Unfortunately I don't have a way to troubleshoot myself at the moment, but I'm definitely happy to explain why things work they way they do if you have questions!
I am not sure if this is related, but there is an error here:
https://github.com/bitwalker/distillery/blob/master/priv/libexec/commands/win/install.ps1#L35
This line:
$service_argv += @("-data", "$Env:START_ERL_DATA)
should be:
$service_argv += @("-data", $Env:START_ERL_DATA)
The above fixes the deployment on Windows for us.
@kiru your fix worked for me as well, @bitwalker bump?