Sven Rautenberg: (TOMCAT) (CUMULUS) Datei wird nicht gefunden

Moin!

Ich habe diesmal eine etwas verzwicktere "Supportanfrage" und hoffe mal auf hilfreiche allgemeine, vielleicht aber auch konkrete Hinweise für die Lösung.

Ich habe einen AMD64-Server mit Gentoo Linux, Kernel 2.6.11, dazu das JDK "dev-java/blackdown-jdk 1.4.2.01-r2".

Auf dem Server läuft unter anderem (und das bislang ohne Probleme) der "Cumulus 6 Workgroup Server", ein Programm zur Verwaltung von Assets. Der Zugriff vom Web aus soll über ein JSP-basiertes Zusatzmodul namens "Web Publisher Pro (WPP)" erfolgen. Und genau dieses macht leider Probleme.

Die Anmeldeseite von WPP ist erreichbar, aber jeglicher Anmeldeversuch scheitert, mit der folgenden Meldung in den Logfiles:

ERROR 2005-06-08 16:36:40,509 [  Thread-2] com.canto.cumulus.web.tags.BaseTag  - Error:
java.lang.UnsatisfiedLinkError: /var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so: /var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
[... die nachfolgenden Zeilen, sofern interessant, gibts auf Nachfrage gerne auch noch...]

Ich hoffe, dass sich jemand mit Java und JSP soweit auskennt, mir zu sagen, welche Ursache dieses "Nichtfinden" der gewünschten Datei haben könnte. Denn das Problem ist: Die libCumulusJCBoot.so existiert dort, wo sie angeblich gesucht wird, und sie darf von allen gelesen und auch ausgeführt werden.

Der Herstellersupport hat leider mit dem Hinweis, Gentoo nicht zu unterstützen, schon aufgegeben.

  • Sven Rautenberg
  1. Hi,

    Ich hoffe, dass sich jemand mit Java und JSP soweit auskennt, mir zu sagen, welche Ursache dieses "Nichtfinden" der gewünschten Datei haben könnte. Denn das Problem ist: Die libCumulusJCBoot.so existiert dort, wo sie angeblich gesucht wird, und sie darf von allen gelesen und auch ausgeführt werden.

    Gilt das mit den Lese-/Ausführ-Rechten auch für die Verzeichnisse obendrüber?

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    Schreinerei Waechter
    Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
    1. Moin!

      Ich hoffe, dass sich jemand mit Java und JSP soweit auskennt, mir zu sagen, welche Ursache dieses "Nichtfinden" der gewünschten Datei haben könnte. Denn das Problem ist: Die libCumulusJCBoot.so existiert dort, wo sie angeblich gesucht wird, und sie darf von allen gelesen und auch ausgeführt werden.

      Gilt das mit den Lese-/Ausführ-Rechten auch für die Verzeichnisse obendrüber?

      Ja, alle Verzeichnisse gehören root:root und sind 755.

      • Sven Rautenberg
  2. Hallo MudGuard,

    für mich sieht es so aus, das es Probleme gibt ein native Libary über das JNI (Java Natice Interface) zu laden.

    Ist WPP closed-Source oder Open-Source? Ich kenn die Software nicht.

    Vielleicht lässt sich das nochwas machen, wenn der Sourcecode vorhanden ist.

    Viele Grüße

    FZwo

    1. sorry meinte eigentlich den Sven

      Hallo MudGuard,

    2. Moin!

      für mich sieht es so aus, das es Probleme gibt ein native Libary über das JNI (Java Natice Interface) zu laden.

      Ist WPP closed-Source oder Open-Source? Ich kenn die Software nicht.

      Vielleicht lässt sich das nochwas machen, wenn der Sourcecode vorhanden ist.

      Das ist genau das Problem, für mich sieht WPP ziemlich nach Closed Source aus.

      • Sven Rautenberg
  3. Hallo Sven,

    [... die nachfolgenden Zeilen, sofern interessant, gibts auf Nachfrage gerne auch noch...]

    Bitte ja.

    Grüße
    Thomas

    --
    Surftip: kennen Sie schon Pipolino's Clowntheater?
    http://www.clowntheater-pipolino.net/
    1. Moin!

      [... die nachfolgenden Zeilen, sofern interessant, gibts auf Nachfrage gerne auch noch...]

      Bitte ja.

      Hier sind sie (aktuell vom Server, welcher trotz ein paar Änderungen immer noch dasselbe Problem zeigt):

      ERROR 2005-06-09 12:16:20,091 [  Thread-2] com.canto.cumulus.web.tags.BaseTag  - Error:
      java.lang.UnsatisfiedLinkError: /var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so: /var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so: cannot open shared object file: No such file or directory
              at java.lang.ClassLoader$NativeLibrary.load(Native Method)
              at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
              at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
              at java.lang.Runtime.loadLibrary0(Runtime.java:788)
              at java.lang.System.loadLibrary(System.java:834)
              at com.canto.cumulus.Cumulus.CumulusStart(Cumulus.java:430)
              at com.canto.cumulus.Cumulus.CumulusStart(Cumulus.java:390)
              at com.canto.cumulus.web.pub.CumulusEnvironment.valueBound(CumulusEnvironment.java:66)
              at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1265)
              at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:191)
              at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:191)
              at org.apache.jasper.runtime.PageContextImpl.setAttribute(PageContextImpl.java:252)
              at com.canto.cumulus.web.tags.UseServerTag.handleStartTag(UseServerTag.java:109)
              at com.canto.cumulus.web.tags.BaseTag.doStartTag(BaseTag.java:160)
              at org.apache.jsp.SelectCatalog_jsp._jspx_meth_cumulus_useServer_0(SelectCatalog_jsp.java:185)
              at org.apache.jsp.SelectCatalog_jsp._jspService(SelectCatalog_jsp.java:91)
              at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
              at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204)
              at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
              at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
              at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
              at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
              at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
              at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
              at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
              at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
              at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
              at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
              at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
              at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
              at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
              at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
              at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
              at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
              at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
              at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
              at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
              at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
              at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
              at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
              at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
              at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
              at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
              at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
              at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432)
              at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386)
              at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534)
              at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530)
              at java.lang.Thread.run(Thread.java:534)

      • Sven Rautenberg
      1. Hallo Sven,

        Hier sind sie (aktuell vom Server, welcher trotz ein paar Änderungen immer noch dasselbe Problem zeigt):

        Da ich nicht so viel Ahnung davon habe, zeigte ich es meinem Kollegen.
        Was ihn dazu einfällt (ohne die software zu kennen) war, dass da libCumulusJCBoot.so ja existiert wäre es möglich, dass die Version des shared object files, also libCumulusJCBoot.so nicht mit der Version, die die java-klasse erwartet übereinstimmt. D.h. vielleicht erwartet die java-klasse einen mMthode für die kein nativer code in libCumulusJCBoot.so existiert.

        Mehr konnten wir jetzt auch nicht zusammenreimen.

        Grüße
        Thomas

        --
        Surftip: kennen Sie schon Pipolino's Clowntheater?
        http://www.clowntheater-pipolino.net/
        1. Moin!

          Da ich nicht so viel Ahnung davon habe, zeigte ich es meinem Kollegen.

          Dazu erstmal vielen Dank.

          Was ihn dazu einfällt (ohne die software zu kennen) war, dass da libCumulusJCBoot.so ja existiert wäre es möglich, dass die Version des shared object files, also libCumulusJCBoot.so nicht mit der Version, die die java-klasse erwartet übereinstimmt. D.h. vielleicht erwartet die java-klasse einen mMthode für die kein nativer code in libCumulusJCBoot.so existiert.

          Klingt irgendwie nicht so überzeugend. Die Java-Klasse und die Lib sind beide vom Hersteller und wurden gemeinsam installiert. Wenn die nicht zusammenpassen sollten, wäre das seeehr merkwürdig.

          • Sven Rautenberg
  4. Hallo,

    hast Du schon mal die system calls mit strace verfolgt? Möglicherweise bringt Dir das weitere Infos.

    Viele Grüße
    Frank

    1. Moin!

      hast Du schon mal die system calls mit strace verfolgt? Möglicherweise bringt Dir das weitere Infos.

      Noch nicht so wirklich, aber vielleicht kann mir ja jemand diese Codewüste noch etwas erklären:

      strace -p 6610 -f -e trace=file

      [pid  6634] stat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", {st_mode=S_IFREG|0555, st_size=4033, ...}) = 0
      [pid  6634] lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
      [pid  6634] lstat("/var/Cumulus5", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
      [pid  6634] lstat("/var/Cumulus5/WPPro", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
      [pid  6634] lstat("/var/Cumulus5/WPPro/CumulusJavaRuntime", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
      [pid  6634] lstat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
      [pid  6634] lstat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", {st_mode=S_IFREG|0555, st_size=4033, ...}) = 0
      [pid  6634] open("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", O_RDONLY) = 15
      [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/lib/amd64/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
      [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/lib/amd64/server/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
      [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/lib/amd64/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
      [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/../lib/amd64/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
      [pid  6634] stat("./libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
      [pid  6634] stat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", {st_mode=S_IFREG|0555, st_size=4033, ...}) = 0
      [pid  6634] open("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", O_RDONLY) = 15
      [pid  6634] stat("/var/Cumulus5/WPPro/jakarta-tomcat-4.1.18/webapps/Cumulus_D/WEB-INF/classes/org/apache/log4j/spi/ThrowableInformation.class", 0x41f959a0) = -1 ENOENT (No such file or directory)

      Die letzte Zeile (sowie die nachfolgenden) scheinen mir dann alle in Zusammenhang mit dem Werfen einer Exception zu stehen, die letztendlich in einer "error.jsp" verarbeitet wird und mutmaßlich die Meldung an den Browser schickt.

      Spannende Frage: Was soll mir der Rückgabecode "15" sagen, der bei der gefundenen Bibliothek steht?

      • Sven Rautenberg
      1. Hallo,

        [pid  6634] stat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", {st_mode=S_IFREG|0555, st_size=4033, ...}) = 0
        [pid  6634] lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
        [pid  6634] lstat("/var/Cumulus5", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
        [pid  6634] lstat("/var/Cumulus5/WPPro", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
        [pid  6634] lstat("/var/Cumulus5/WPPro/CumulusJavaRuntime", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
        [pid  6634] lstat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
        [pid  6634] lstat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", {st_mode=S_IFREG|0555, st_size=4033, ...}) = 0
        [pid  6634] open("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", O_RDONLY) = 15
        [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/lib/amd64/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
        [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/lib/amd64/server/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
        [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/lib/amd64/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
        [pid  6634] stat("/opt/blackdown-jdk-1.4.2.01/jre/../lib/amd64/libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)
        [pid  6634] stat("./libCumulusJCBoot.so", 0x41f95c80) = -1 ENOENT (No such file or directory)

        Die Bibliothek wird in verschiedenen Verzeichnissen gesucht und nicht gefunden.

        [pid  6634] stat("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", {st_mode=S_IFREG|0555, st_size=4033, ...}) = 0
        [pid  6634] open("/var/Cumulus5/WPPro/CumulusJavaRuntime/lib/libCumulusJCBoot.so", O_RDONLY) = 15

        Die Bibliothek wird schließlich in /var/Cumulus5/WPPro/CumulusJavaRuntime/lib/ gefunden und geöffnet. Der Ablauf ist so weit normal.

        [pid  6634] stat("/var/Cumulus5/WPPro/jakarta-tomcat-4.1.18/webapps/Cumulus_D/WEB-INF/classes/org/apache/log4j/spi/ThrowableInformation.class", 0x41f959a0) = -1 ENOENT (No such file or directory)

        Diese Datei wird nicht gefunden. Liegt hier vielleicht das Problem?

        Die letzte Zeile (sowie die nachfolgenden) scheinen mir dann alle in Zusammenhang mit dem Werfen einer Exception zu stehen, die letztendlich in einer "error.jsp" verarbeitet wird und mutmaßlich die Meldung an den Browser schickt.

        Spannende Frage: Was soll mir der Rückgabecode "15" sagen, der bei der gefundenen Bibliothek steht?

        Das ist der Filedescriptor, der von open() zurückgegeben wird. Was mich auch wundert: im Ablauf sind zwei open()-Calls, die jeweils den gleichen Descriptor 15 zurückgeben, ohne dass zwischendurch ein close() erfolgt.

        Viele Grüße
        Frank

  5. Moin!

    Dem beschriebenen Problem wurde ausgewichen, indem einfach ein anderer Server (32 Bit) mit anderem Linux (Debian) und anderem JDK (Sun 1.4.2) benutzt wurde.

    Keine Ahnung, warum das jetzt funktioniert, aber das Ergebnis zählt.

    • Sven Rautenberg