Static executables in minimal Docker containers

[Michael Snoyman]

I'm trying to put together a minimal Docker container consisting of nothing but GHC-compiled static executables. Below you can see a full interaction I've had with GHC and Docker. The high level summary is that:

* When compiled statically, the executable runs just fine in both my host OS (Ubuntu 14.04) and an Ubuntu 14.04 Docker image

* That same executable run from a busybox (or a "scratch" image, not shown here since it's slightly longer to set up) hangs and then runs out of memory

I've watched the process in top, and it uses up a huge amount of CPU and memory. I get the same behavior whether I compiled with or without optimizations or the multithreaded runtime. I also get identical behavior with both GHC 7.8.4 and 7.10.1.

I'm not sure how best to proceed with trying to debug this, any suggestions?

vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ cat > hello.hs <<EOF

main :: IO ()

main = putStrLn "Static Hello"

EOF

vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ghc -optl-static -optl-pthread hello.hs -static

[1 of 1] Compiling Main             ( hello.hs, hello.o )

Linking hello ...

/opt/ghc/7.8.4/lib/ghc-7.8.4/rts-1.0/libHSrts.a(Linker.o): In function `internal_dlopen':

(.text+0x5c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ./hello

Static Hello

vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ docker run --rm -v $(pwd)/hello:/usr/local/bin/hello:ro ubuntu:14.04 /usr/local/bin/hello

Static Hello

vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ docker run --rm -v $(pwd)/hello:/usr/local/bin/hello:ro busybox /usr/local/bin/hello

hello: out of memory (requested 1048576 bytes)

vagrant@vagrant-ubuntu-trusty-64:~/Desktop$ ghc --version

The Glorious Glasgow Haskell Compilation System, version 7.8.4

[Michael Snoyman]

On Mon, Apr 13, 2015 at 12:07 PM Magnus Therning <mag...@therning.org> wrote:

On 13 April 2015 at 10:54, Michael Snoyman <mic...@snoyman.com> wrote:
> I'm trying to put together a minimal Docker container consisting of nothing
> but GHC-compiled static executables. Below you can see a full interaction
> I've had with GHC and Docker. The high level summary is that:
>
> * When compiled statically, the executable runs just fine in both my host OS
> (Ubuntu 14.04) and an Ubuntu 14.04 Docker image
> * That same executable run from a busybox (or a "scratch" image, not shown
> here since it's slightly longer to set up) hangs and then runs out of memory

From what I remember busybox allows for quite a bit of
configurability, so "a busybox" might need a bit more details mabye.

Have you attempted running it under `strace` and/or `ltrace`?

Sorry, I left off a word: I meant "a busybox image." There's a standard busybox Docker image which I'm testing with via the command I pasted below. There are certainly ways to configure busybox itself, but it should be trivial for others to reproduce this error simply by running my series of commands.

Unfortunately, strace and ltrace aren't available in that Docker image, but it's a good idea to see if I can get them running there somehow.

Michael 

[Sharif Olorin]

Unfortunately, strace and ltrace aren't available in that Docker image, but it's a good idea to see if I can get them running there somehow.

Failing that, you might be able to get useful information of the same kind by running docker (the server, not the `docker run` command) under perf[0] and then running your busybox container. It should at least give you an idea of what it's doing when it explodes.

Sharif

[0]: https://perf.wiki.kernel.org/index.php/Tutorial

[Greg Weber]

Haskell is not that great at producing statically linked libraries independent of the OS.

The issue you are running into would likely show up in another non-ubuntu image (or even possibly a different version of an ubuntu image), so you could probably use a Fedora image that has tracing.

How are you addressing the linker warning about needing a particular glibc version at runtime?

--
You received this message because you are subscribed to the Google Groups "Commercial Haskell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to commercialhask...@googlegroups.com.
To post to this group, send email to commerci...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-f09703f2be67%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Snoyman]

I'm not sure if this issue would show up, but I can try it in Fedora tomorrow. I didn't address the linker warning at all right now, it seems to not have been triggered, though I suppose it is possible that it's the cause of this issue.

[Simon Marlow]

Hi Michael,

This rang a bell for me. It might be the same as these:
https://ghc.haskell.org/trac/ghc/ticket/7695
https://ghc.haskell.org/trac/ghc/ticket/8928

I think the conclusion was that the IO library is failing to start
iconv, and printing the error messages causes it to retry loading iconv,
ad infinitum (or something like that). There's no fix yet, but it
probably isn't hard to fix, just that nobody got around to it yet.

Cheers,
Simon

> <mailto:commercialhask...@googlegroups.com>.

> To post to this group, send email to
> commerci...@googlegroups.com

> <mailto:commerci...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-f09703f2be67%40googlegroups.com

> <https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-f09703f2be67%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Commercial Haskell" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to commercialhask...@googlegroups.com

> <mailto:commercialhask...@googlegroups.com>.

> To post to this group, send email to commerci...@googlegroups.com

> <mailto:commerci...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_5GWPO1Dcn%2BvwsiB_xWj%2B8GfHvMkoBjw%40mail.gmail.com
> <https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_5GWPO1Dcn%2BvwsiB_xWj%2B8GfHvMkoBjw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Michael Snoyman]

Thanks for the update Simon.

To unsubscribe from this group and stop receiving emails from it, send an email to commercialhask...@googlegroups.com.
To post to this group, send email to commerci...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/553407EF.1030303%40gmail.com.