bitwalker / distillery

Simplify deployments in Elixir with OTP releases!
MIT License
2.96k stars 398 forks source link

Can't start application on windows 10 #599

Open jsayegh opened 5 years ago

jsayegh commented 5 years ago

Steps to reproduce

{"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

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|Qv_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

Lazarus404 commented 5 years ago

Creating a release for Windows is quite a nightmare. Having similar issues. I was getting the above, but now it just hangs completely.

Lazarus404 commented 5 years ago

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
PaoloLaurenti commented 5 years ago

@Lazarus404 the problem you've mentioned has been solved with this commit: https://github.com/bitwalker/distillery/commit/c42a47d36e5247f4798a04ac806dcdb7edaaf3fb

Lazarus404 commented 5 years ago

The problem is, if I use branch master, the release hangs completely, with no error message.

Lazarus404 commented 5 years ago

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
Lazarus404 commented 5 years ago

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.

PaoloLaurenti commented 5 years ago

@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...

Lazarus404 commented 5 years ago

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?

Lazarus404 commented 5 years ago

Okay, so, it's being re-set in several places, including the release apps own ps1 file :) Not so clean.

bitwalker commented 5 years ago

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.

Lazarus404 commented 5 years ago

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.

Lazarus404 commented 5 years ago

@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?

bitwalker commented 5 years ago

@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!

kiru commented 3 years ago

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.

brooksmtownsend commented 2 years ago

@kiru your fix worked for me as well, @bitwalker bump?