one more item on commons-daemon I found out what the issue was. The commons-daemon-native.tar.gz file contains archive library and object files in the unix directory that were compiled on some other system. I would recommend that this tar file is repackaged, doing a make clean in the unix directory before repackaging. http://www.junlu.com/list/8/655090.html
keep us apprised, Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: jason.c.bu...@wellsfargo.com > To: user@commons.apache.org > Date: Fri, 23 Jul 2010 19:01:14 -0500 > Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through JSVC > but not when natively called > > Sorry Martin, still at a loss. I don't get the reference as to how > stripping debug code from libraries applies here (I understand what you're > saying and agree with it, I just don't see how it is relevant here). > > I have an application that ran fine under IBM JRE 5 and jsvc 1.0.1 and > 1.0.2. I upgraded to IBM JRE 6 and now I get the link exception. The code > hasn't changed - unless you're referring to the IBM JRE library? If that > was the case, why would it work when the JVM is created by the JRE's > bin/java command? > > Perhaps someone knows of a way to get more debugging information from the > JVM? As I showed in my previous post, we can see where in the code the link > error is happening, but perhaps a more verbose JRE library would tell me > why? Anyone know of such a thing? > > Or have any other ideas? > > Jason > > > > -----Original Message----- > > From: Martin Gainty [mailto:mgai...@hotmail.com] > > Sent: Friday, July 23, 2010 11:29 AM > > To: user@commons.apache.org > > Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through > > JSVC but not when natively called > > > > > > > > > > sometimes when programmers strip their debug code they also strip working > > code so the rule is > > > > debug library always work..a programmer could'nt declare working code > > without a debug library > > > > production library (without the debug statements) usually work..if not > > fall back to debug library > > > > > > > > take a look at Doug Kileys solution for JSVC problem with Snow Leopard..he > > used 1.02 commons daemon to fix > > > > https://issues.apache.org/jira/browse/DAEMON-129 > > > > in this case the culprit was commons-daemon 1.01 > > > > upgrade to commons-daemon 1.01 with patches or > > > > upgrade to commons-daemon 1.02 and see if that resolves > > > > > > > > keep us apprised, > > Martin Gainty > > ______________________________________________ > > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > > > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > > dient lediglich dem Austausch von Informationen und entfaltet keine > > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E- > > Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > > destinataire prévu, nous te demandons avec bonté que pour satisfaire > > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la > > copie de ceci est interdite. Ce message sert à l'information seulement et > > n'aura pas n'importe quel effet légalement obligatoire. Étant donné que > > les email peuvent facilement être sujets à la manipulation, nous ne > > pouvons accepter aucune responsabilité pour le contenu fourni. > > > > > > > > > > > > > From: jason.c.bu...@wellsfargo.com > > > To: user@commons.apache.org > > > Date: Thu, 22 Jul 2010 19:42:34 -0500 > > > Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through > > JSVC but not when natively called > > > > > > Thanks for the reply Martin, but I'm a little confused. After reading > > the > > > page you sent, it seems kdb is a kernel debugger for processing system > > > dumps. This is a java exception from the JVM running in user space. > > There > > > is no dump file and unless I'm missing something, I don't know how the > > > kernel trace is going to help me here. Can you perhaps just give a bit > > more > > > information about what you had in mind? Thanks for taking the time to > > > reply. > > > > > > Jason > > > > > > > -----Original Message----- > > > > From: Martin Gainty [mailto:mgai...@hotmail.com] > > > > Sent: Thursday, July 22, 2010 5:28 PM > > > > To: user@commons.apache.org > > > > Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through > > > > JSVC but not when natively called > > > > > > > > > > > > load in kdb and read the debug output back > > > > http://www.aixmind.com/?p=637 > > > > > > > > > > > > > > > > hth > > > > Martin Gainty > > > > ______________________________________________ > > > > do not alter ot disrupt this transmission. Thank You > > > > > > > > > > > > > > > > > > > > > From: jason.c.bu...@wellsfargo.com > > > > > To: user@commons.apache.org > > > > > Date: Thu, 22 Jul 2010 17:18:56 -0500 > > > > > Subject: [daemon]UnsatisfiedLinkError: net exception thown through > > JSVC > > > > but not when natively called > > > > > > > > > > Hopefully the mailing list can help where I have failed after > > pulling my > > > > > hair out for three days. Any advice will be greatly appreciated. > > > > > > > > > > I have an AIX 5.2 machine with daemons 1.0.2 and IBM's latest JRE 6 > > > > > installed: > > > > > > > > > > bash-3.1# ./jre/bin/java -version > > > > > java version "1.6.0" > > > > > Java(TM) SE Runtime Environment (build pap3260sr8-20100409_01(SR8)) > > > > > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32 > > > > > jvmap3260sr8-20100401_55940 (JIT enabled, AOT enabled) > > > > > J9VM - 20100401_055940 > > > > > JIT - r9_20100401_15339 > > > > > GC - 20100308_AA) > > > > > JCL - 20100408_01 > > > > > > > > > > 1.0.2 is compiled with > > > > > > > > > > ./configure --with-java=$(JAVA_HOME) > > > > > make > > > > > > > > > > This includes a small patch to location.c and appsupport.m4 just to > > > > enable > > > > > jsvc to find the jvm.cfg and libjvm.so files during startup. > > > > > > > > > > I have a Java application that implements the Daemon class. I'm > > trying > > > > to > > > > > update the JRE from 5 to 6 - this application worked fine under 5 > > and > > > > > upgraded on other OSes to 6 with no issues. Part of the > > initialization > > > > of > > > > > this class is a routine to create an RMI registry. A partial example > > is > > > > > below: > > > > > > > > > > From the Daemon class: > > > > > > > > > > public void init(DaemonContext arg0) throws Exception > > > > > { > > > > > log.debug("Initializing client from the Daemon process."); > > > > > > > > > > log.debug("Setting environment variables."); > > > > > System.setProperty("javax.net.ssl.trustStore", "<snip>"); > > > > > System.setProperty("javax.net.ssl.trustStoreType", "jks"); > > > > > > > > > > <snip> > > > > > > > > > > log.debug("Initializing client."); > > > > > client = new Client(); > > > > > if (arg0 == null) > > > > > client.init(null); > > > > > else > > > > > client.init(arg0.getArguments()); > > > > > > > > > > <snip> > > > > > > > > > > hasInit = true; > > > > > log.debug("Initializing done."); > > > > > } > > > > > > > > > > And from the Client class: > > > > > > > > > > public void init(String[] cmdArgs) > > > > > { > > > > > log.debug("Initializing Client."); > > > > > > > > > > <snip> > > > > > > > > > > try > > > > > { > > > > > // Set up RMI for <something>. Start with the registry. > > > > > if (rmiRegistry == null) > > > > > { > > > > > log.debug("Trying to start the rmi registry."); > > > > > rmiRegistry = LocateRegistry.createRegistry(rmiport); > > > > > log.debug("Registry started."); > > > > > } > > > > > <snip> > > > > > } > > > > > catch (Exception e) > > > > > <snip> > > > > > } > > > > > > > > > > > > > > > When this process starts up through JSVC, it crashes in > > createRegistry > > > > with > > > > > a UnsatisfiedLinkError. Below is the jsvc debug output: > > > > > > > > > > > > > > > jsvc debug: +-- DUMPING PARSED COMMAND LINE ARGUMENTS -------------- > > > > > jsvc debug: | Detach: False > > > > > jsvc debug: | Show Version: No > > > > > jsvc debug: | Show Help: No > > > > > jsvc debug: | Check Only: Disabled > > > > > jsvc debug: | Stop: False > > > > > jsvc debug: | Wait: 0 > > > > > jsvc debug: | Run as service: No > > > > > jsvc debug: | Install service: No > > > > > jsvc debug: | Remove service: No > > > > > jsvc debug: | JVM Name: "null" > > > > > jsvc debug: | Java Home: "null" > > > > > jsvc debug: | PID File: "<client home>/run/client.pid" > > > > > jsvc debug: | User Name: "null" > > > > > jsvc debug: | Extra Options: 2 > > > > > jsvc debug: | > > > > > "-Djava.class.path=./libs/commons-daemon.jar:./ClientSoftware.jar" > > > > > jsvc debug: | Class Invoked: "<package>.Daemon" > > > > > jsvc debug: | Class Arguments: 0 > > > > > jsvc debug: +------------------------------------------------------- > > > > > jsvc debug: Home not specified on command line, using environment > > > > > jsvc debug: Attempting to locate Java Home in <client home>/jre > > > > > jsvc debug: Attempting to locate VM configuration file <client > > > > > home>/jre/jre/lib/jvm.cfg > > > > > jsvc debug: Attempting to locate VM configuration file <client > > > > > home>/jre/lib/jvm.cfg > > > > > jsvc debug: Attempting to locate VM configuration file <client > > > > > home>/jre/jre/lib/ppc/jvm.cfg > > > > > jsvc debug: Attempting to locate VM configuration file <client > > > > > home>/jre/lib/ppc/jvm.cfg > > > > > jsvc debug: Found VM configuration file at <client > > > > home>/jre/lib/ppc/jvm.cfg > > > > > jsvc debug: Found VM j9vm definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/j9vm/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/j9vm/libjvm.so > > > > > jsvc debug: Found VM client definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/client/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/client/libjvm.so > > > > > jsvc debug: Cannot locate library for VM client (skipping) > > > > > jsvc debug: Found VM server definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/server/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/server/libjvm.so > > > > > jsvc debug: Cannot locate library for VM server (skipping) > > > > > jsvc debug: Found VM hotspot definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/hotspot/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/hotspot/libjvm.so > > > > > jsvc debug: Cannot locate library for VM hotspot (skipping) > > > > > jsvc debug: Found VM classic definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/classic/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/classic/libjvm.so > > > > > jsvc debug: Found VM native definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/native/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/native/libjvm.so > > > > > jsvc debug: Cannot locate library for VM native (skipping) > > > > > jsvc debug: Found VM green definition in configuration > > > > > jsvc debug: Checking library <client > > > > home>/jre/jre/lib/ppc/green/libjvm.so > > > > > jsvc debug: Checking library <client > > home>/jre/lib/ppc/green/libjvm.so > > > > > jsvc debug: Cannot locate library for VM green (skipping) > > > > > jsvc debug: Java Home located in <client home>/jre > > > > > jsvc debug: +-- DUMPING JAVA HOME STRUCTURE ------------------------ > > > > > jsvc debug: | Java Home: "<client home>/jre" > > > > > jsvc debug: | Java VM Config.: "<client home>/jre/lib/ppc/jvm.cfg" > > > > > jsvc debug: | Found JVMs: 2 > > > > > jsvc debug: | JVM Name: "j9vm" > > > > > jsvc debug: | "<client home>/jre/lib/ppc/j9vm/libjvm.so" > > > > > jsvc debug: | JVM Name: "classic" > > > > > jsvc debug: | "<client home>/jre/lib/ppc/classic/libjvm.so" > > > > > jsvc debug: +------------------------------------------------------- > > > > > jsvc debug: redirecting stdout to /dev/null and stderr to /dev/null > > > > > jsvc debug: Using default JVM in <client > > > > home>/jre/lib/ppc/j9vm/libjvm.so > > > > > jsvc debug: Attemtping to load library <client > > > > > home>/jre/lib/ppc/j9vm/libjvm.so > > > > > jsvc debug: JVM library <client home>/jre/lib/ppc/j9vm/libjvm.so > > loaded > > > > > jsvc debug: JVM library entry point found (0x2004E12C) > > > > > jsvc debug: +-- DUMPING JAVA VM CREATION ARGUMENTS ----------------- > > > > > jsvc debug: | Version: 0x010006 > > > > > jsvc debug: | Ignore Unrecognized Arguments: False > > > > > jsvc debug: | Extra options: 3 > > > > > jsvc debug: | > > > > > "-Djava.class.path=./libs/commons-daemon.jar:./ClientSoftware.jar" > > > > > (0x00000000) > > > > > jsvc debug: +------------------------------------------------------- > > > > > jsvc debug: Java VM created successfully > > > > > jsvc debug: Class org/apache/commons/daemon/support/DaemonLoader > > found > > > > > jsvc debug: Native methods registered > > > > > jsvc debug: java_init done > > > > > jsvc debug: Daemon loading... > > > > > java.lang.reflect.InvocationTargetException > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > > at > > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: > > > > 48 > > > > > ) > > > > > at > > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm > > > > pl > > > > > .java:25) > > > > > at java.lang.reflect.Method.invoke(Method.java:600) > > > > > at > > > > > > > > > > > org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:156) > > > > > Caused by: java.lang.UnsatisfiedLinkError: net (A file or directory > > in > > > > the > > > > > path name does not exist.) > > > > > at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1008) > > > > > at > > > > > > > java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:972) > > > > > at java.lang.System.loadLibrary(System.java:470) > > > > > at > > > > > sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:69) > > > > > at > > > > > > > java.security.AccessController.doPrivileged(AccessController.java:202) > > > > > at java.net.InetAddress.<clinit>(InetAddress.java:217) > > > > > at java.lang.J9VMInternals.initializeImpl(Native Method) > > > > > at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) > > > > > at sun.rmi.transport.tcp.TCPEndpoint.<clinit>(TCPEndpoint.java:95) > > > > > at java.lang.J9VMInternals.initializeImpl(Native Method) > > > > > at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) > > > > > at sun.rmi.transport.LiveRef.<init>(LiveRef.java:75) > > > > > at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:77) > > > > > at > > > > > > > java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:198) > > > > > at <package>.Client.init(Client.java:570) > > > > > at <package>.Daemon.init(Daemon.java:95) > > > > > ... 5 more > > > > > 22/07/2010 14:42:42 1077390 jsvc error: Cannot load daemon > > > > > jsvc debug: java_load failed > > > > > 22/07/2010 14:42:42 1130686 jsvc error: Service exit with a return > > value > > > > of > > > > > 3 > > > > > > > > > > > > > > > Removing jsvc from the picture by creating a main method in Daemon > > that > > > > just > > > > > creates a Daemon object, calls daemon.init(), then calls > > daemon.start() > > > > runs > > > > > as expected (well, except for actually being a daemon =) ). > > > > > > > > > > An unsatified error of 'net' really intrigued me since this looks > > like > > > > maybe > > > > > "java.net"? How could it not find a runtime library? I thought that > > > > > perhaps jsvc was setting some odd boot path or class path for the > > jvm, > > > > so I > > > > > printed out all the system properities in the Daemon.init method. > > The > > > > list > > > > > of properties from the jsvc run and the bin/java run are exactly the > > > > same. > > > > > So it doesn't appear to be that easy of a solution. > > > > > > > > > > Running both jsvc and bin/java with the verbose flag and checking > > which > > > > > order the classes load shows something interesting: > > > > > > > > > > jsvc: > > > > > > > > > > <snip>... > > > > > class load: java/net/InetAddress > > > > > class load: sun/security/action/LoadLibraryAction > > > > > class load: java/lang/UnsatisfiedLinkError > > > > > class load: java/lang/J9VMInternals$1 > > > > > java.lang.reflect.InvocationTargetException > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > > ...<snip> > > > > > > > > > > bin/java: > > > > > > > > > > <snip>... > > > > > class load: java/net/InetAddress > > > > > class load: sun/security/action/LoadLibraryAction > > > > > class load: java/net/InetAddress$Cache > > > > > class load: java/net/InetAddress$Cache$Type > > > > > ...<snip> > > > > > > > > > > > > > > > So if the code is loading the libraries in a consistent fashion > > (don't > > > > think > > > > > this is guaranteed, but the rest of the class loading output seems > > to > > > > imply > > > > > that this is probable), it seems that the code when run through jsvc > > > > bombs > > > > > when trying to load the Cache internal class to InetAddress? This > > seems > > > > odd > > > > > to me since they should be in the same library, no? > > > > > > > > > > > > > > > Anyway, I'm at a loss at this point. This code upgraded to JRE 6 on > > all > > > > > other platforms just fine. On this AIX platform, however, it just > > > > doesn't > > > > > seem to like jsvc. I'm hoping someone else has seen this or has more > > > > > intimate knowledge with the JVM and can point me in the right > > direction. > > > > > Again, I appreciate any assistance anyone can provide. > > > > > > > > > > Thanks, > > > > > Jason > > > > > > > > > > > > > _________________________________________________________________ > > > > The New Busy is not the old busy. Search, chat and e-mail from your > > inbox. > > > > > > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON > > > > :WL:en-US:WM_HMP:042010_3 > > > > _________________________________________________________________ > > Hotmail has tools for the New Busy. Search, chat and e-mail from your > > inbox. > > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON > > :WL:en-US:WM_HMP:042010_1 _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
