Hi Jungs und Mädels,

ich versuche gerade Java auf unserem Linux Server zu installieren. Dazu habe ich folgende Anleitung befolgt und mir das bin (nicht das RPM) Package runtergeladen. Da ich keine Root-Rechte besitze.

http://java.sun.com/javase/6/webnote...elf-extracting

So weit so gut. Die Installation lief auch Fehlerfrei. Letzte Meldung:

Code :

1

Done.

Wenn ich jetzt jedoch versuche z.B. java -version oder generell nur java im Ordner bin auszuführen bekomme ich folgenden Fehler:

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

Und hier stehe ich auf dem Schlauch. Jemand eine Idee?

Hallo,

was sagt denn "ldd ./java"? Da siehst du gegen welche libjli die jvm gelinkt ist. Befindet sich diese in dem dort angezeigten Verzeichnis?

Gruß,
RedWing

ldd sagt folgendes:

Code :

1 2 3 4 5 6 7

(21:35:02) [bin] ldd ./java         linux-gate.so.1 =>  (0x4ef05000)         libpthread.so.0 => /lib/libpthread.so.0 (0x4ee94000)         libjli.so => not found         libdl.so.2 => /lib/libdl.so.2 (0x4ee8f000)         libc.so.6 => /lib/libc.so.6 (0x4ed79000)         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4eeef000)

Wirst du daraus schlau?

Im Javaordner:

Code :

1	ln -s $(find . -name libjli.so -type f) libjli.so

(ungetestet)

Wenn ich das eingebe bekomme ich nichts angezeigt einfach nur den nächsten leeren Prompt. Er hat wohl eine libjli.so erstellt. Allerdings liefert der Aufruf java -version immernoch den gleichen Fehler. Ich habe es im Ordner java und im Ordner java/bin getestet.

Noch eine Idee?

Hallo,

Zitat von Maik20

ldd sagt folgendes:

Code :

1 2 3 4 5 6 7

(21:35:02) [bin] ldd ./java         linux-gate.so.1 =>  (0x4ef05000)         libpthread.so.0 => /lib/libpthread.so.0 (0x4ee94000)         libjli.so => not found         libdl.so.2 => /lib/libdl.so.2 (0x4ee8f000)         libc.so.6 => /lib/libc.so.6 (0x4ed79000)         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4eeef000)

Wirst du daraus schlau?

hast du das Java Binary außerhalb des bin Ordners verschoben? Normalerweise wird java gegen $ORIGIN/../lib/i386/jli/libjli.so gelinkt. $ORIGIN ist eine Variable die so im Binary gespeichert ist, welche der Linker dann in das Verzeichnis auflöst in dem dein Programm liegt. Anhand des relativen Pfades sollte das binary ein Verzeichnis unterhalb deines Java Installationspfades liegen ansonsten passt der Linkpfad nicht und der dynamische Linker kann den Pfad zur Bibliothek nicht auflösen!

Es gibt 2 Möglichkeiten:

1.) Wenn du das binary tatsächlich aus welchen Gründen auch immer verschoben hast, solltest du stattdessen ein Link anlegen:

Bspw.:

Code :

1	ln -s /home/redwing/jre1.6.0_11/bin/java /usr/bin/java

Wichtig ist das das ursprüngliche Binary in /pfad/zur/java/installation/jre1.6.0_11/bin/ liegen bleiben muss.

2.) Wenn dem nicht so sein sollte, dann setze die Umgebungsvariable LD_LIBRARY_PATH auf das Verzeichnis wo libjli.so liegt:

Bspw:

Code :

1	export LD_LIBRARY_PATH=/home/redwing/jre1.6.0_11/lib/i386/jli/

Gruß,
RedWing

Hallo,

hab grad noch gelesen das das Binary bei dir wohl im bin Ordner liegt. Das erschwert die ganze Angelegenheit nat. Kannst du mir mal bitte den Link zu genau dem Java-Archiv schicken was du installiert hast?

Danke,
RedWing

Danke für die Hilfe. Link ist in der PM.

Hallo,

hab es gerade mal mit deinem Archiv ausprobiert. Daran liegt es wirklich nicht...

Zwei Sachen fallen mir noch dazu ein:

1.) Dein Linker ist aus irgendeinem Grund zu alt um $ORIGIN auflösen zu können. Kannst du mir mal die Version sagen? Einfach die Ausgabe von "ls /lib/ld*" betrachten. Ich habe bspw. ld-2.7.so

2.) Bei den Zugriffsrechten deines Binaries (java) ist aus irgendeinem Grund das sgid bzw suid Bit gesetzt, denn laut Manpage wird der Linker genau dann $ORIGIN nicht auflösen aus Sicherheitsgründen. Ich schätze dieses Szenario allerdings eher als unwahrscheinlich ein... Rausfinden kannst du das indem du dir die Dateirechte der Datei mit "ls -al" anguckst. Wenn da bei den Zugriffsrechten bei User oder Gruppe ein "s" stehen sollte dann sind sie aktiviert.

Hast du denn mal das mit dem setzen der Umgebungsvariable LD_LIBRARY_PATH probiert? Falls dies auch nicht funktionieren sollte könnte das Theorie 2 stützen

So sieht das bei mir aus:

Code :

1 2 3 4 5 6 7 8 9 10 11 12 13 14

redwing@euklid:~/jre1.6.0_07/bin$ pwd /home/redwing/jre1.6.0_07/bin redwing@euklid:~/jre1.6.0_07/bin$ readelf -a ./java | grep ORIGIN  0x0000000f (RPATH)                      Library rpath: [$ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli] redwing@euklid:~/jre1.6.0_07/bin$ ldd ./java     linux-gate.so.1 =>  (0xffffe000)     libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7f3b000)     libjli.so => /home/redwing/jre1.6.0_07/bin/../lib/i386/jli/libjli.so (0xb7f31000)     libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f2d000)     libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7dd2000)     /lib/ld-linux.so.2 (0xb7f72000) redwing@euklid:~/jre1.6.0_07/bin$ ls ../lib/i386/jli/ libjli.so redwing@euklid:~/jre1.6.0_07/bin$

Wie sieht das bei dir aus?

Gruß,
RedWing

Hi RedWing,

zu 1) Version 2.3.4

/lib/ld-2.3.4.so /lib/ld-linux.so.2

zu 2) Nein kein "s" zu sehen.

-rwxr-x--- 1 user1 nobody 19754758 2008-06-19 19:05 jre-6u7-linux-i586.bin

Ich habe jetzt mal versucht den LD_LIBRARY_PATH zu setzten. In Analogie zu deinem Verzeichnis. Anschließend bekomme ich folgende Ausgabe von ldd ./java
Eine java -version schlägt dennoch fehl. Siehe unten:

(15:27:49) [bin] ldd ./java
linux-gate.so.1 => (0x50b6b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x50afa000)
libjli.so => /kunden/12345/tmp/jre1.6.0_07/lib/i386/jli/libjli.so (0x50af0000)
libdl.so.2 => /lib/libdl.so.2 (0x50aec000)
libc.so.6 => /lib/libc.so.6 (0x509d6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x50b55000)
(15:27:54) [bin] ./java -version
Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location - find_vma failed
(15:28:03) [bin]

Noch eine Idee?

Hi,

nein leider nicht, mehr als googlen kann ich da auch nicht. Aber google ist zu deiner letzten Fehlermeldung recht gesprächig. Was des öfteren geschrieben wird, ist das viele bei denen das Problem auftritt java innerhalb einer chroot- Umgebung laufen lassen, aber in welcher das /proc- Verzeichnis nicht gemountet ist. Dieses Verzeichnis ist ein virtuelles Verzeichnis welches der Linuxkern nutz um seiner Außenwelt (also dem Rest des Betriebssystems) eine Schnittstelle anbieten zu können durch welche Kernelfunktionen in gewisser Weise vom Userland aus gesteuert und der aktuelle Zustand von Prozessmagement, Gerätetreiber, CPU-infos usw. ausgelesen werden kann. Dieses braucht java wohl um zur Initialisierungszeit etwas über seinen Prozess zu erfahren.
Ist dies bei dir der Fall (also das mit dem chroot)?

Außerdem kommt mir dein Linker recht alt vor (ca 4 - 7 Jahre - anhand der Version zu erkennen). Es könnte sein (das kann ich aber nicht genau sagen) das er diesen RPATH Mechanismus mit $ORIGIN nicht handeln kann. Besteht die Möglichkeit nach einem Systemupdate? Das Problem ist, das, wenn ich mich nicht irre, der Laufzeit Linker ein Bestandteil der glibc ist. Du müsstest also glibc auch updaten, und somit quasi dein ganzes System...

Außerdem, welche Kernelversion hast du?

Gruß,
RedWing

Danke für die Hilfe.

ein Systemupdate ist nicht möglich. Es handelt sich um einen virtuellen Web-Server mit SSH-Zugang und der Provider macht kein Update.

Ich googel mich mal etwas durch die Gegend.

Danke

Maik

Hi,

Zitat von Maik20

Danke für die Hilfe.

ein Systemupdate ist nicht möglich. Es handelt sich um einen virtuellen Web-Server mit SSH-Zugang und der Provider macht kein Update.

Ich googel mich mal etwas durch die Gegend.

Danke

Maik

ok, nichts zu danken. Eine Frage noch: Existiert bei dir /proc?

Gruß,
RedWIng

Ja.

/proc existiert