I missed this thread but I guess I tried something similar last month: https://gist.github.com/noteed/4155ffad2b1d13ab17ee 2015-04-13 20:50 GMT+02:00 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.

On Mon, Apr 13, 2015 at 7:10 PM Greg Weber wrote:

...

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?

On Mon, Apr 13, 2015 at 3:28 AM, Sharif Olorin wrote:

...

...

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

-- 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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-....

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

I wonder whether you already know the following, and whether it is relevant to begin with. (Plus, my knowledge is fairly sketchy.) Even though you statically link glibc, its code will, at run time, dlopen a certain part of glibc. Why: To provide a really uniform abstraction layer over user account queries, e.g., man 3 getpwnam, regardless of whether the accounts are from /etc/passwd, LDAP, or whatever. Therefore, during run time, glibc first reads some config files of the host to see what kind of user account database the host uses. If it's /etc/passwd, then dlopen the implementation of getpwnam and friends for /etc/passwd; else, if it's LDAP, then dlopen the implementation of getpwnam and friends for LDAP; etc etc. So that later when you call getpwnam, it will happen to "do the right thing". This demands the required *.so files to be accessible during run time. Moreoever, if you statically link glibc, this also demands the required *.so files to version-match the glibc you statically link. (It is the main reason why most people give up on statically linking glibc.)

Actually, I seem to have found the problem: open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) I found that I needed to copy over the following files to make my program complete: /usr/lib/x86_64-linux-gnu/gconv/gconv-modules /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so Once I did that, I could get the executable to run in the chroot. However, even running the statically linked executable still required most of the shared libraries to be present inside the chroot. So it seems that: * We can come up with a list of a few files that need to be present inside a Docker image to provide for minimal GHC-compiled executables * There's a bug in the RTS that results in an infinite loop I'm going to try to put together a semi-robust solution for the first problem, and I'll report the RTS issue on Trac. On Tue, Apr 14, 2015 at 9:25 AM Michael Snoyman wrote:

I have a bit more information about this. In particular: I'm able to reproduce this using chroot (no Docker required), and it's reproducing with a dynamically linked executable too. Steps I used to reproduce:

1. Write a minimal "foo.hs" containing `main = putStrLn "Hello World"` 2. Compile that executable and put it in an empty directory 3. Run `ldd` on it and copy all necessary libraries inside that directory 4. Run `sudo strace -o log.txt . /foo`

I've uploaded the logs to:

https://gist.github.com/snoyberg/095efb17e36acc1d6360

Note that, due to size of the output, I killed the process just a few seconds after starting it, but when I let the output run much longer, I didn't see any difference in the results. I'll continue poking at this a bit, but most likely I'll open a GHC Trac ticket about it later today.

On Tue, Apr 14, 2015 at 12:39 AM Albert Y. C. Lai wrote:

...

I wonder whether you already know the following, and whether it is relevant to begin with. (Plus, my knowledge is fairly sketchy.)

Even though you statically link glibc, its code will, at run time, dlopen a certain part of glibc.

Why: To provide a really uniform abstraction layer over user account queries, e.g., man 3 getpwnam, regardless of whether the accounts are from /etc/passwd, LDAP, or whatever.

Therefore, during run time, glibc first reads some config files of the host to see what kind of user account database the host uses. If it's /etc/passwd, then dlopen the implementation of getpwnam and friends for /etc/passwd; else, if it's LDAP, then dlopen the implementation of getpwnam and friends for LDAP; etc etc.

So that later when you call getpwnam, it will happen to "do the right thing".

This demands the required *.so files to be accessible during run time. Moreoever, if you statically link glibc, this also demands the required *.so files to version-match the glibc you statically link.

(It is the main reason why most people give up on statically linking glibc.) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Trac ticket created: https://ghc.haskell.org/trac/ghc/ticket/10298#ticket I've also put together a Docker image called snoyberg/haskell-scratch (source at https://github.com/snoyberg/haskell-scratch), which seems to be working for me. Here's a minimal test I've put together which seems to be succeeding (note that I've also tried some real life programs): #!/bin/bash set -e set -x cat > tiny.hs < Dockerfile < wrote:

Actually, I seem to have found the problem:

open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I found that I needed to copy over the following files to make my program complete:

/usr/lib/x86_64-linux-gnu/gconv/gconv-modules /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so

Once I did that, I could get the executable to run in the chroot. However, even running the statically linked executable still required most of the shared libraries to be present inside the chroot. So it seems that:

* We can come up with a list of a few files that need to be present inside a Docker image to provide for minimal GHC-compiled executables * There's a bug in the RTS that results in an infinite loop

I'm going to try to put together a semi-robust solution for the first problem, and I'll report the RTS issue on Trac.

On Tue, Apr 14, 2015 at 9:25 AM Michael Snoyman wrote:

...

I have a bit more information about this. In particular: I'm able to reproduce this using chroot (no Docker required), and it's reproducing with a dynamically linked executable too. Steps I used to reproduce:

1. Write a minimal "foo.hs" containing `main = putStrLn "Hello World"` 2. Compile that executable and put it in an empty directory 3. Run `ldd` on it and copy all necessary libraries inside that directory 4. Run `sudo strace -o log.txt . /foo`

I've uploaded the logs to:

https://gist.github.com/snoyberg/095efb17e36acc1d6360

Note that, due to size of the output, I killed the process just a few seconds after starting it, but when I let the output run much longer, I didn't see any difference in the results. I'll continue poking at this a bit, but most likely I'll open a GHC Trac ticket about it later today.

On Tue, Apr 14, 2015 at 12:39 AM Albert Y. C. Lai wrote:

...

I wonder whether you already know the following, and whether it is relevant to begin with. (Plus, my knowledge is fairly sketchy.)

Even though you statically link glibc, its code will, at run time, dlopen a certain part of glibc.

Why: To provide a really uniform abstraction layer over user account queries, e.g., man 3 getpwnam, regardless of whether the accounts are from /etc/passwd, LDAP, or whatever.

Therefore, during run time, glibc first reads some config files of the host to see what kind of user account database the host uses. If it's /etc/passwd, then dlopen the implementation of getpwnam and friends for /etc/passwd; else, if it's LDAP, then dlopen the implementation of getpwnam and friends for LDAP; etc etc.

So that later when you call getpwnam, it will happen to "do the right thing".

This demands the required *.so files to be accessible during run time. Moreoever, if you statically link glibc, this also demands the required *.so files to version-match the glibc you statically link.

(It is the main reason why most people give up on statically linking glibc.) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

The /lib/ version of the file was necessary for statically linked executables I believe. It's arguably better to just remove it and tell people "don't do static executables" I suppose, given that they're clearly not *actually* static in reality ;) On Sat, Apr 18, 2015, 12:51 PM Vo Minh Thu wrote:

Michael, thanks for solving this !

I wonder how you came up with the need for /lib/ld-linux-x86-64.so.2. I have needed only /lib64/ld-linux-x86-64.so.2 (which you have too), so maybe you added it by mistake.

B.t.w, if you don't want to use a Dockerfile, you can do this:

> tar -C rootfs -c . | docker import - tiny

where rootfs is your repository.

...

Trac ticket created: https://ghc.haskell.org/trac/ghc/ticket/10298#ticket

I've also put together a Docker image called snoyberg/haskell-scratch (source at https://github.com/snoyberg/haskell-scratch), which seems to be working for me. Here's a minimal test I've put together which seems to be succeeding (note that I've also tried some real life programs):

#!/bin/bash

set -e set -x

cat > tiny.hs <

ghc tiny.hs strip tiny

cat > Dockerfile <

docker build -t tiny . docker run --rm tiny

On Tue, Apr 14, 2015 at 9:52 AM Michael Snoyman wrote:

...

Actually, I seem to have found the problem:

open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) =

-1

...

ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I found that I needed to copy over the following files to make my

...

...

complete:

/usr/lib/x86_64-linux-gnu/gconv/gconv-modules /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so

Once I did that, I could get the executable to run in the chroot. However, even running the statically linked executable still required most of the shared libraries to be present inside the chroot. So it seems that:

* We can come up with a list of a few files that need to be present inside a Docker image to provide for minimal GHC-compiled executables * There's a bug in the RTS that results in an infinite loop

I'm going to try to put together a semi-robust solution for the first problem, and I'll report the RTS issue on Trac.

On Tue, Apr 14, 2015 at 9:25 AM Michael Snoyman wrote:

...

I have a bit more information about this. In particular: I'm able to reproduce this using chroot (no Docker required), and it's reproducing

with

...

a dynamically linked executable too. Steps I used to reproduce:

1. Write a minimal "foo.hs" containing `main = putStrLn "Hello World"` 2. Compile that executable and put it in an empty directory 3. Run `ldd` on it and copy all necessary libraries inside that

2015-04-14 10:43 GMT+02:00 Michael Snoyman : program directory

...

...

...

4. Run `sudo strace -o log.txt . /foo`

I've uploaded the logs to:

https://gist.github.com/snoyberg/095efb17e36acc1d6360

Note that, due to size of the output, I killed the process just a few seconds after starting it, but when I let the output run much longer, I didn't see any difference in the results. I'll continue poking at this a bit, but most likely I'll open a GHC Trac ticket about it later today.

On Tue, Apr 14, 2015 at 12:39 AM Albert Y. C. Lai wrote:

...

I wonder whether you already know the following, and whether it is relevant to begin with. (Plus, my knowledge is fairly sketchy.)

Even though you statically link glibc, its code will, at run time, dlopen a certain part of glibc.

Why: To provide a really uniform abstraction layer over user account queries, e.g., man 3 getpwnam, regardless of whether the accounts are from /etc/passwd, LDAP, or whatever.

Therefore, during run time, glibc first reads some config files of the host to see what kind of user account database the host uses. If it's /etc/passwd, then dlopen the implementation of getpwnam and friends

for

...

/etc/passwd; else, if it's LDAP, then dlopen the implementation of getpwnam and friends for LDAP; etc etc.

So that later when you call getpwnam, it will happen to "do the right thing".

This demands the required *.so files to be accessible during run time. Moreoever, if you statically link glibc, this also demands the required *.so files to version-match the glibc you statically link.

(It is the main reason why most people give up on statically linking glibc.) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

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 On 13/04/2015 11:50, Michael Snoyman wrote:

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.

On Mon, Apr 13, 2015 at 7:10 PM Greg Weber mailto:greg@gregweber.info> wrote:

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?

On Mon, Apr 13, 2015 at 3:28 AM, Sharif Olorin mailto:sharif.olorin@gmail.com> wrote:

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

-- 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 commercialhaskell+unsubscribe@googlegroups.com mailto:commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com mailto:commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-... 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 commercialhaskell+unsubscribe@googlegroups.com mailto:commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com mailto:commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_... https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_5GWPO1Dcn%2BvwsiB_xWj%2B8GfHvMkoBjw%40mail.gmail.com?utm_medium=email&utm_source=footer. For more options, visit https://groups.google.com/d/optout.

Hi, I had the same bug with a single static binary in a initramfs. I fixed GHC.IO.Encoding to avoid using Iconv for the default (ASCII) charmap used with static binaries and now it works. Patch is in my comment on https://ghc.haskell.org/trac/ghc/ticket/10298 If the default LC_CTYPE value is the DEFAULT_CHARMAP from glibc/locale/programs/config.h, it is set to "ANSI_X3.4-1968" since 2000 and was set to "POSIX" before. Maybe we should match this one too? Sylvain 2015-04-20 6:34 GMT+02:00 Michael Snoyman :

Thanks for the update Simon.

On Sun, Apr 19, 2015 at 10:54 PM Simon Marlow wrote:

...

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

On 13/04/2015 11:50, Michael Snoyman wrote:

...

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.

On Mon, Apr 13, 2015 at 7:10 PM Greg Weber mailto:greg@gregweber.info> wrote:

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?

On Mon, Apr 13, 2015 at 3:28 AM, Sharif Olorin mailto:sharif.olorin@gmail.com> wrote:

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

-- 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 commercialhaskell+unsubscribe@googlegroups.com mailto:commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com mailto:commercialhaskell@googlegroups.com. To view this discussion on the web visit

https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-...

...

<

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 commercialhaskell+unsubscribe@googlegroups.com mailto:commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com mailto:commercialhaskell@googlegroups.com. To view this discussion on the web visit

https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_...

...

< https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_5GWPO1Dcn%2BvwsiB_xWj%2B8GfHvMkoBjw%40mail.gmail.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 commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/553407EF.1030303%40gmail... . For more options, visit https://groups.google.com/d/optout.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe