Compiling certifi fails on docker with Alpine Linux

[mschae]

Same as benoitc/erlang-idna#13:

==> certifi (compile)
Killed
** (Mix) Could not compile dependency :certifi, "/root/.mix/rebar compile skip_deps=true deps_dir="/app/_build/development/lib"" command failed. You can recompile this dependency with "mix deps.compile certifi", update it with "mix deps.update certifi" or clean it with "mix deps.clean certifi"

Docker image running alpine linux and OTP 18.5

[mschae]

Ok it gets even more fun. I tried compiling it manually using rebar.

The first time it failed:

/app/deps/certifi # /root/.mix/rebar compile
==> certifi (compile)
Killed

The second time it worked:

/app/deps/certifi # /root/.mix/rebar compile
==> certifi (compile)
Compiled src/certifi.erl
Compiled src/certifi_cacerts.erl
Compiled src/certifi_weakcerts.erl

I did absolutely nothing in between... :(

[benoitc]

thanks for the report. i will try to reproduce tuomorrow on a machine where mix is installed. i will update the ticket asap :) On Thu, 17 Mar 2016 at 19:46, Michael Schaefermeyer < notifications@github.com> wrote:

Ok it gets even more fun. I tried compiling it manually using rebar.

The first time it failed:

/app/deps/certifi # /root/.mix/rebar compile ==> certifi (compile) Killed

The second time it worked:

/app/deps/certifi # /root/.mix/rebar compile ==> certifi (compile) Compiled src/certifi.erl Compiled src/certifi_cacerts.erl Compiled src/certifi_weakcerts.erl

I did absolutely nothing in between... :(

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/certifi/erlang-certifi/issues/6#issuecomment-198029552

[benoitc]

hrm I don't reproduce it at all

[erlang-certifi] rebar compile                                                                                      15:59:37  ☁  master ☀
==> erlang-certifi (compile)
Compiled src/certifi.erl
Compiled src/certifi_weakcerts.erl
Compiled src/certifi_cacerts.erl

either way hackney have been updated to be installed using mix.

[mschae]

Thanks for looking into this @benoitc and sorry for the late reply.

This only happens on Alpine on Docker for me, let me try to give you a container and test project to illustrate the problem...

[mschae]

It might be worthwhile to make @msaraiva aware of this as well as it seems limited to Alpine docker containers on my end.

[benoitc]

@mschae in between can you provide me a clear path on how you're using this docker image? Could help to reproduce the issue :)

[mschae]

@benoitc I have something better... :)

https://github.com/mschae/compileerrors/

It includes the Docker build log, running on my OS X Docker machine:

docker-machine version 0.6.0, build e27fb87
Docker version 1.10.1, build 9e83765

[benoitc]

@mschae how much ram did you allowed to your instance?

[mschae]

I didn't change the default setting which is 1024mb.

[mschae]

Ah! I increased RAM to 4096mb and it compiled!

Since this is one-off it's not a clear indicator but this is definitely a hint...

[mschae]

Tried it a couple of times across different projects, increasing the RAM seems to have done the trick!

Merci beaucoup Benoit!

[benoitc]

@mschae thanks for the feedback :) I should definitely solve this memory issue during compiling. One way would be compiling the beam only in escripts. In other case the data could be cached in an ETS eventually. I will think more about it.

[mschae]

@benoitc Thanks for pointing me in the right direction. Most crucial was to figure out how we can continue to compile reliably. And with merely increasing the memory we achieve that. That was most crucial to me.

So glad that we can continue using hackney, it's a very crucial part of our SOA ecosystem, we use it in 6 apps (that I can think of, probably more).

[msaraiva]

@mschae thanks for letting me know about this issue.

[benoitc]

closing as it has been answered