Sự cố khi khởi chạy java tại Debian: Lỗi trong khi tải thư viện dùng chung: libjli.so

Tôi đang cố gắng khởi chạy java:

$ java -version
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

$ ldd /usr/lib/jvm/java-6-openjdk/jre/bin/java
        linux-gate.so.1 =>  (0xb779f000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7780000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7767000)
        libjli.so => /usr/lib/jvm/java-6-openjdk/jre/bin/../lib/i386/jli/libjli.so (0xb7762000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb775e000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7603000)
        /lib/ld-linux.so.2 (0xb77a0000
$ ls /usr/lib/jvm/java-6-openjdk/jre/bin/../lib/i386/jli/
libjli.so

Nhưng java hoạt động dưới quyền root:

$ sudo java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~lenny1)
OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)

CẬP NHẬT:

/ usr / lib / jvm / java-6-openjdk / jre / bin / java thực sự là lệnh java của tôi:

$ type java
java is hashed (/usr/bin/java)
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Jul 14 10:15 /usr/bin/java -> /etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 40 Jul 14 10:36 /etc/alternatives/java -> /usr/lib/jvm/java-6-openjdk/jre/bin/java

CẬP NHẬT2:

Tôi cũng đã cố gắng thiết lập PATH gốc:

$ sudo su
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# exit
$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ java -version
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

CẬP NHẬT 3:

Tôi mệt:

# comm -3 <(declare | sort) <(declare -f | sort)

dưới gốc. Nhưng không có biến môi trường có thể sử dụng cho java.

CẬP NHẬT 4:

strace -f java -versionkết quả: http://dumpz.org/67368/

open("$ORIGIN/../lib/i386/jli/tls/i686/sse2/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

Thực thi bạn đang chạy vẻ cho các thư viện trong một rPath ngoài các đường dẫn tìm kiếm thư viện bình thường. Sự thông cảm ở đây là $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Thông thường $ORIGINnên được thay thế bởi vị trí của thực thi, ở đây /usr/lib/jvm/java-6-openjdk/jre/bin.

Ở đây, $ORIGINkhông được thay thế. Tính năng này bị tắt trong các tệp thực thi đang chạy với các đặc quyền bổ sung (setuid, setgid hoặc setpcap), vì nếu không, bạn có thể tiêm một thư viện khác và do đó chạy mã tùy ý với các đặc quyền nâng cao. (Xem bài viết này để được giải thích chi tiết hơn.) Vấn đề bảo mật được phát hiện tương đối gần đây; trong Debian nó đã được sửa trong DSA-2122-1 , vì vậy trước khi bạn nâng cấp lên libc6-2.7-18lenny6, javakhả năng thực thi của bạn có lẽ đã hoạt động.

Các triệu chứng chỉ ra rằng javađang chạy với các đặc quyền bổ sung. Đây không phải là trường hợp cài đặt Debian bình thường. Đảm bảo rằng đó /usr/lib/jvm/java-6-openjdk/jre/bin/javalà chế độ 755 và không có bất kỳ khả năng nào ( getcap /usr/lib/jvm/java-6-openjdk/jre/bin/javavà setcap -r …để loại bỏ các khả năng đó nếu có).

(Câu trả lời gốc, có thể hữu ích nếu bạn thấy nó javahoạt động với quyền root chứ không phải như những người dùng khác và hóa ra bạn đang gọi các nhị phân khác nhau.)

Đặt cược của tôi là bạn có một số javaphiên bản khác sớm hơn trên PATH( sudothay đổi PATH). Kiểm tra những gì type javanói - có thể là một số phiên bản Java khác nhau để ldd /path/to/bin/javabáo cáo libjli.so => not found.

Và tôi suy đoán rằng lý do mà phiên bản Java này không thể tìm thấy libjli.solà vì nó tìm kiếm nó thông qua một đường dẫn (đường dẫn tìm kiếm thư viện được lưu trữ trong tệp thực thi) không khớp với cách cài đặt. Nếu bạn có javatệp nhị phân /some/where/bin/javavà nó có một đường dẫn tương đối (đó là cách của Sun JDK và OpenJDK), thư viện sẽ nằm trong /some/where/lib/i386/jli/libjli.so(giả sử kiến ​​trúc i386). Nếu rPath là tuyệt đối, bạn cần phải hoặc đặt libjli.sotrong các quy định chính xác vị trí, hoặc thiết lập LD_LIBRARY_PATHđể bao gồm nơi libjli.solà.

Tôi đã tải xuống "1.7.0_60" từ java.com ở .tar.gzđịnh dạng và cài đặt nó vào /usr/local/jre1.7.0_60. Sau đó tôi đã tạo một liên kết cứng đến /usr/local/bin/javavà nhận được lỗi được mô tả ở trên.

Thay đổi liên kết cứng thành liên kết tượng trưng đã khắc phục sự cố.

Phiên bản ngắn:

$ sudo ln /usr/local/jre1.7.0_60/bin/java /usr/local/bin/java

Là xấu.

$ sudo ln -s /usr/local/jre1.7.0_60/bin/java /usr/local/bin/java

Tốt.

Cố gắng tìm java thực thi bên trong cùng một đường dẫn libjli.sovà sử dụng nó.

Ví dụ như tôi thấy libjli.sotrong /usr/lib/jvm/java-7-oracle/jre/lib/amd64/jli/libjli.so, vì vậy tôi sử dụng

find /usr/lib/jvm/java-7-oracle/ -name "java"

và tìm thấy thực thi trong /usr/lib/jvm/java-7-oracle/bin/java. Sau đó, tôi xóa javatừ /usr/binvà chỉ liên kết trên thực thi vào /usr/bin.

Nếu lỗi là do sử dụng setcap trên tệp thực thi Java, thì hãy tham khảo

Làm cách nào để Oracle java 7 hoạt động với setcap cap_net_bind_service + ep và http://bugs.java.com/view_orms.do?orms_id=7157699

trong đó trả lời chi tiết câu hỏi này

ps. Trong dự án của chúng tôi, chúng tôi đã phải làm

sudo setcap cap_net_bind_service=+ep /path/to/java

để cho phép java nhị phân mở các cổng tcp / udp dưới 1024. Trên java "bug" 7157699 cung cấp giải pháp nhanh chóng, bằng cách thêm thư mục nơi libjli.so được đặt vào một tệp conf trong đường dẫn /etc/ld.so.conf.d và sau đó gọi ldconfig để thư viện lại bộ đệm. Giả sử Linux.

Kiểm tra các quyền trên tập tin đó. Họ nên trông như thế 0644/-rw-r--r--. Nếu không, hãy cài đặt lại openjdk-6-jre-headless, vì điều đó có nghĩa là ai đó bị rối với các quyền.

Tương tự như câu trả lời của Tshepang, tôi buộc phải libjli.sovào con đường tìm kiếm thư viện:

# find / usr / lib / jvm -name \ libjli.so
/usr/lib/jvm/java-6-sun-1.6.0.45/jre/lib/amd64/jli/libjli.so

# xuất LD_LIBRARY_PATH = / usr / lib / jvm / java-6-sun / jre / lib / amd64 / jli: $ LD_LIBRARY_PATH

Để tham khảo, môi trường xây dựng của tôi sử dụng github: flexiondotorg / oab-java6 trên Ubuntu 10.04 / 64-bit.

Đối với một số lý do kỳ lạ /usr/bin/javađã không còn chỉ đến cài đặt java. Không biết làm thế nào điều này xảy ra. Tôi đã xác nhận điều này bằng cách chạy:

$ sudo update-alternatives --config java

Mà đã cho tôi như sau

There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
Nothing to configure.
update-alternatives: warning: forcing reinstallation of alternative /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java because link group java is broken
update-alternatives: warning: not replacing /usr/bin/java with a link

Vì vậy, giải pháp là loại bỏ java trong /usr/local/binvà tạo một liên kết tượng trưng mới:

$ sudo rm -rf /usr/bin/java
$ sudo ln -s /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java /usr/bin/java

Tôi đã có những lỗi giống nhau.

Cách đơn giản nhất để giải quyết nó là chỉ cần loại bỏ tất cả jdks và jres và cả tệp thực thi / usr / bin / java, nếu có.

Và sau đó cài đặt lại jdk.

Nó giải quyết vấn đề cho tôi. Trong khi các phương pháp khác thì không.

Đối với bất kỳ ai đang cố gắng khởi động ứng dụng Java từ dịch vụ systemd và nhận được cùng một lỗi, liên quan đến libjli.sothư viện, hãy đọc tiếp.

Hiện tại có một lỗi mở cho Fedora:

Lỗi 1358476 - SELinux ngăn chặn systemd thực thi các dịch vụ dựa trên java

Kết quả cuối cùng là Selinux đang âm thầm hạn chế quyền truy cập vào thư viện đó. Vì không có tin nhắn bị từ chối AVC, bạn không thể sửa nó bằng ngữ cảnh hoặc thay đổi chính sách.

Tôi đã thấy rằng việc thêm một tệp /etc/ld.so.conf.d/chứa thư mục libjli.sotệp của bạn là một cách giải quyết:

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-5.b14.fc26.x86_64/jre/lib/amd64/jli/

Và sau đó chạy

ldconfig

Nhưng điều đó khá lộn xộn ...

Một tùy chọn tốt hơn là sử dụng /bin/bash -cđể khởi chạy quy trình Java trong tệp dịch vụ của bạn:

ExecStart=/bin/bash -c "/usr/bin/java -Xmx1024m -jar myApp.jar NONINTERACTIVE"

Cho đến khi vấn đề được khắc phục ....