libjli.so is missing for java:8-jre-alpine

[cdelgehier]

Hello

When i run my zookeeper some errors

Error loading shared library libjli.so: No such file or directory (needed by /usr/lib/jvm/default-jvm/bin/java)
Error relocating /usr/lib/jvm/default-jvm/bin/java: JLI_Launch: symbol not found

$ docker run --rm -ti java:8-jre-alpine sh
/ # ldd /usr/lib/jvm/default-jvm/bin/java
    /lib/ld-musl-x86_64.so.1 (0x7f60e8a6d000)
Error loading shared library libjli.so: No such file or directory (needed by /usr/lib/jvm/default-jvm/bin/java)
    libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f60e8a6d000)
Error relocating /usr/lib/jvm/default-jvm/bin/java: JLI_Launch: symbol not found

$ docker info
Containers: 6
 Running: 0
 Paused: 0
 Stopped: 6
Images: 279
Server Version: 1.11.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: xfs
 Dirs: 294
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.19.0-32-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.62 GiB
ID: 5I4K:MM6Y:MNCI:R5WU:JQRL:OFHQ:LGJR:EC2A:MYJN:PFRW:GO56:KLAK
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: cdelgehier
Registry: https://index.docker.io/v1/

[yosifkit]

This looks to be an issue with the alpine packaging of the jre. Could you open an issue with them? Or maybe @ncopa can look into this?

$ docker run -it --rm alpine:3.3 sh
/ # apk add --no-cache openjdk8-jre
fetch http://dl-cdn.alpinelinux.org/alpine/v3.3/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.3/community/x86_64/APKINDEX.tar.gz
(1/24) Installing libffi (3.2.1-r2)
(2/24) Installing libtasn1 (4.7-r1)
(3/24) Installing p11-kit (0.23.1-r1)
(4/24) Installing p11-kit-trust (0.23.1-r1)
(5/24) Installing openssl (1.0.2h-r0)
(6/24) Installing ca-certificates (20160104-r2)
(7/24) Installing java-cacerts (1.0-r0)
(8/24) Installing libxau (1.0.8-r1)
(9/24) Installing libxdmcp (1.1.2-r1)
(10/24) Installing libxcb (1.11.1-r0)
(11/24) Installing libx11 (1.6.3-r2)
(12/24) Installing libxext (1.3.3-r1)
(13/24) Installing libxi (1.7.5-r0)
(14/24) Installing libxrender (0.9.9-r1)
(15/24) Installing libxtst (1.2.2-r0)
(16/24) Installing libpng (1.6.20-r0)
(17/24) Installing freetype (2.6.2-r0)
(18/24) Installing libgcc (5.3.0-r0)
(19/24) Installing giflib (5.1.1-r0)
(20/24) Installing openjdk8-jre-lib (8.92.14-r0)
(21/24) Installing java-common (0.1-r0)
(22/24) Installing alsa-lib (1.1.0-r1)
(23/24) Installing openjdk8-jre-base (8.92.14-r0)
(24/24) Installing openjdk8-jre (8.92.14-r0)
Executing busybox-1.24.1-r7.trigger
Executing ca-certificates-20160104-r2.trigger
Executing java-common-0.1-r0.trigger
OK: 105 MiB in 35 packages
/ # java
Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)
where options include:
    -d32      use a 32-bit data model if available
    -d64      use a 64-bit data model if available
    -server   to select the "server" VM
                  The default VM is server,
                  because you are running on a server-class machine.


    -cp <class search path of directories and zip/jar files>
    -classpath <class search path of directories and zip/jar files>
                  A : separated list of directories, JAR archives,
                  and ZIP archives to search for class files.
    -D<name>=<value>
                  set a system property
    -verbose:[class|gc|jni]
                  enable verbose output
    -version      print product version and exit
    -version:<value>
                  Warning: this feature is deprecated and will be removed
                  in a future release.
                  require the specified version to run
    -showversion  print product version and continue
    -jre-restrict-search | -no-jre-restrict-search
                  Warning: this feature is deprecated and will be removed
                  in a future release.
                  include/exclude user private JREs in the version search
    -? -help      print this help message
    -X            print help on non-standard options
    -ea[:<packagename>...|:<classname>]
    -enableassertions[:<packagename>...|:<classname>]
                  enable assertions with specified granularity
    -da[:<packagename>...|:<classname>]
    -disableassertions[:<packagename>...|:<classname>]
                  disable assertions with specified granularity
    -esa | -enablesystemassertions
                  enable system assertions
    -dsa | -disablesystemassertions
                  disable system assertions
    -agentlib:<libname>[=<options>]
                  load native agent library <libname>, e.g. -agentlib:hprof
                  see also, -agentlib:jdwp=help and -agentlib:hprof=help
    -agentpath:<pathname>[=<options>]
                  load native agent library by full pathname
    -javaagent:<jarpath>[=<options>]
                  load Java programming language agent, see java.lang.instrument
    -splash:<imagepath>
                  show splash screen with specified image
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.
/ # which java
/usr/bin/java
/ # ldd /usr/bin/java
    /lib/ld-musl-x86_64.so.1 (0x562c83948000)
Error loading shared library libjli.so: No such file or directory (needed by /usr/bin/java)
    libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x562c83948000)
Error relocating /usr/bin/java: JLI_Launch: symbol not found
/ # ldd $(readlink -f /usr/bin/java)
    /lib/ld-musl-x86_64.so.1 (0x56387d169000)
    libjli.so => /usr/lib/jvm/java-1.8-openjdk/jre/bin/../lib/amd64/jli/libjli.so (0x7fc1a52a5000)
    libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x56387d169000)
    libz.so.1 => /lib/libz.so.1 (0x7fc1a508f000)

[ncopa]

it seems that we need ship /usr/lib/jvm/java-1.0-openjdk/lib/amd64/jli/libjli.so with the package openjdk8-jre-base.

It is interesting that /usr/lib/jvm/default-jvm/jre/bin/java works. (note the /jre/)

[yosifkit]

This should be fixed in c6c90f5

[joschi]

@yosifkit The problem still occurs on the latest java:8-jre-alpine image:

$ echo 'FROM openjdk:8-jre-alpine' > Dockerfile

$ docker build .
Sending build context to Docker daemon 3.072 kB
Step 1/1 : FROM openjdk:8-jre-alpine
 ---> d85b17c6762e
Successfully built d85b17c6762e

$ docker run -it d85b17c6762e /bin/sh
/ # ldd $(readlink -f /usr/bin/java)
	/lib/ld-musl-x86_64.so.1 (0x556e4362f000)
	libjli.so => /usr/lib/jvm/java-1.8-openjdk/jre/bin/../lib/amd64/jli/libjli.so (0x7fcd2748d000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x556e4362f000)
	libz.so.1 => /lib/libz.so.1 (0x7fcd27277000)
/ # ldd /usr/bin/java
	/lib/ld-musl-x86_64.so.1 (0x561b9ab3e000)
Error loading shared library libjli.so: No such file or directory (needed by /usr/bin/java)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x561b9ab3e000)
Error relocating /usr/bin/java: JLI_Launch: symbol not found
/ # exit

Any hints on how to fix this?

[ncopa]

It works:

/ # java -version
openjdk version "1.8.0_111-internal"
OpenJDK Runtime Environment (build 1.8.0_111-internal-alpine-r0-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

/usr/bin/java work fine, even if ldd does not because the RPATH is set in the binary:

/ # readelf -d /usr/bin/java | grep RPATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64]

If you manually set LD_LIBRARY_PATH, then will also ldd work:

/ # LD_LIBRARY_PATH=/usr/lib/jvm/java-1.8-openjdk/lib/amd64/jli ldd /usr/bin/java 
	/lib/ld-musl-x86_64.so.1 (0x7618e2e74000)
	libjli.so => /usr/lib/jvm/java-1.8-openjdk/lib/amd64/jli/libjli.so (0x7618e2a64000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7618e2e74000)
	libz.so.1 => /lib/libz.so.1 (0x7618e284e000)

So java works, but there might be an issue with ldd.

[echa]

This worked for me when running java as root, but not as unprivileged user using gosu.

Alpine 3.5.2
musl-1.1.15-r6

The reason seems to be that musl ignores both RPATH and LD_LIBRARY_PATH. The musl docu on LD_LIBRARY_PATH vaguely stats This variable is completely ignored in programs invoked setuid, setgid, or with other elevated capabilities. I haven't checked with the code, but defining the musl equivalent to /etc/ld.so.conf worked (see below).

# gosu graylog sh
$ strace java -version
execve("/usr/bin/java", ["java", "-version"], [/* 18 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fef3c00cb48) = 0
set_tid_address(0x7fef3c00cb80)         = 37
open("/etc/ld-musl-x86_64.path", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libjli.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/libjli.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libjli.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
writev(2, [{iov_base="Error loading shared library lib"..., iov_len=77}, {iov_base="/usr/bin/java", iov_len=13}], 2Error loading shared library libjli.so: No such file or directory (needed by /usr/bin/java) = 90
writev(2, [{iov_base=")", iov_len=1}, {iov_base=NULL, iov_len=0}], 2)) = 1
writev(2, [{iov_base="\n", iov_len=1}, {iov_base=NULL, iov_len=0}], 2
) = 1
mprotect(0x7fef3c009000, 4096, PROT_READ) = 0
writev(2, [{iov_base="Error relocating /usr/bin/java: "..., iov_len=60}, {iov_base=NULL, iov_len=0}], 2Error relocating /usr/bin/java: JLI_Launch: symbol not found) = 60
writev(2, [{iov_base="\n", iov_len=1}, {iov_base=NULL, iov_len=0}], 2
) = 1
mprotect(0x55ba04105000, 4096, PROT_READ) = 0
exit_group(127)                         = ?
+++ exited with 127 +++

My solution was to define all required library paths in /etc/ld-musl-x86_64.path (the file needed to be created)

/lib
/usr/lib
/usr/local/lib
/usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64
/usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli
/usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/server

[tianon]

Closing since this appears solved. If someone is running into this problem still, please open a new issue with a detailed reproducing case that shows it is a problem specific to the image (not to either the Alpine packages or OpenJDK upstream directly). Thanks!

[lossless1]

Just move libjli.so from /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli to /lib.
For me it works like $ mv /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib
And to be sure

$ ldd /usr/bin/java
        /lib/ld-musl-x86_64.so.1 (0x7fc78c95c000)
        libjli.so => /lib/libjli.so (0x7fc78c54c000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fc78c95c000)
        libz.so.1 => /lib/libz.so.1 (0x7fc78c336000)

[christhomas]

The solution from @echa worked perfectly for me. Thanks!