Closed xpdf closed 5 years ago
Seems like the problem is that CONSOLIDATED_DIR
is not set, I'll take a look, in the meantime as a workaround you can export that var manually, it should point into <deploy root>/lib/<relname>-<relvsn>/consolidated
I can't seem to determine why that wouldn't be set, it is in my environment, and should be according to how bash works. Can you tell me what version of bash you are running? I'll see if I can reproduce with CentOS7 in the meantime
So I created a CentOS7 environment, and cloned my example project, but am not able to reproduce the missing CONSOLIDATED_DIR
issue. Can you confirm the specific version of CentOS 7 and bash you are using? It's possible it is a specific version combination that is affected.
Thank you for the very prompt response on this matter.
Confirmed; setting the environment var CONSOLIDATED_DIR as described allows the foreground and console to run with no error.
further info was interesting as my build platform is <> the container versions:
[dh@mack ~]$ bash --version GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
[dh@mack ~]$ rpm --query centos-release centos-release-7-5.1804.4.el7.centos.x86_64
[dh@mack ~]$ docker exec -i -t a85eeec46371 /bin/bash [root@a85eeec46371 2018.910.9051529]# rpm --query centos-release centos-release-7-3.1611.el7.centos.x86_64
[root@a85eeec46371 2018.910.9051529]# bash --version GNU bash, version 4.2.46(1)-release (x86_64-redhat-linux-gnu) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Monday, I will bring the container up to the build version of Cent and bash and provide and update on the result of that.
Thanks again.
Experiencing exactly the same problem when building a container from alpine 3.6. Setting the CONSOLIDATED_DIR variable fixes it. (bash 4.3.48-r1)
I have both build and release platforms on centos-release-7-5.1804.4.el7.centos.x86_64 / bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu); I still have the same problem; what centOS7 version was used in your test?
It wasn’t CentOS, but Linux Alpine.
I've made a few changes to master, one of which probably will fix this issue, but I'd like you to confirm for me if you can. I've moved some exports out of the exec shim and into the main release script, so if CONSOLIDATED_DIR
isn't set, nothing is.
On Friday I pulled from your master at ref: "5add0c92fa620e874be957acd6c7a31671e6da41", took out my added env setting for CONSOLIDATED_DIR in my build and built in my CI pipline. Odd things happened - my custom commands did not work - so migrations did not run, and my build would not deploy as a result, so I could not determine if your fix for the original issue is good.
Over the weekend I was able to recreate this by hand on my build server and when I run the custom command "echo" nothing happens, same as migrate. "help" works - and returns that usage info. I found that if i ran foreground, and then killed it, echo and migrations would now work. This makes absolutely no sense to me.
I can't get a valid release on OSX using this ref in master, when I try to start it with any option I get _build/dev/rel/transport_api/releases/0.0.1/libexec/erts.sh: line 306: : No such file or directory.
I am going to work backwards on commits to see where it broke for me after 2.0.12, and will send that info along as well.
This issue is resolved, I need to make changes in my CI to account for not being able to do migrations the way I was with a custom command after the change "Do not load configs for secondary commands"
Thanks.
Steps to reproduce
Build on CentOS7
All of this build process was working under Distillery 1.5.5, just upgraded to 2.0.10 and worked through upgrade changes, but stuck on why it runs using start, but not foreground...
when I connect to the deployed app in the container and try to run using console option, or foreground options I get: 2018-10-04 10:44:18.135414 Error in process ~p with exit value:~n~p~n transportapi-v2_usertest | <0.2347.0> transportapi-v2_usertest | {function_clause, [{filename,join,[[]],[{file,"filename.erl"},{line,432}]}, {code_server,insert_dir,2,[{file,"code_server.erl"},{line,820}]},{code_server,init_namedb,2,[{file,"code_server.erl"},{line,797}]},{code_server,init_namedb,1,[{file,"code_server.erl"},{line,793}]},{code_server,init,3,[{file,"code_server.erl"},{line,96}]}]}
When I run using the 'start' option the app runs fine.
Verbose Logs
Paste the output of the release command you ran with the
--verbose
flag below in the summary tags (this helps keep the issue easy to navigate):Description of issue
What are the expected results? App runs using the foreground command.
What version of Distillery? 2.0.10
What OS, Erlang/Elixir versions are you seeing this issue on? CentOS7, Elixir 1.7.3, Erlang 21 / 10.1
If possible, also provide your
rel/config.exs
, as it is often my first troubleshooting question, and you'll save us both time :)see details in logs at bottom
Is there documentation that says one thing, but Distillery does another? If so, please link the doc here so it can be updated if it's a documentation issue, or so that the fix can be based around what's documented. Unknown.
If this is a runtime configuration issue, please also provide your config file (with any sensitive information stripped of course). This is almost always necessary to understand why some configuration may not be working.
see details in logs at bottom
If you do not provide the above information and I need it to help troubleshoot, it may delay things significantly, as I will have to ask you for all of these things anyway. Help me help you!