Re: [daemon] Procrun UnsatisfiedLinkError with JNI project
> Maybe try running the service as the same user as the one you use when > running from the command line. That should help narrow down what is > going on. Sorry, I should have mentioned that I had already tried that, and that it made no difference. > >> I guess check the obvious. Does the dll exist where the app is looking? > > > > It does exist yes. I have a working theory in fact that it loads the > > DLL, but it is the dependencies of that DLL (which will be various > > Windows system DLL's) that it can't load. > > Is there a tool (ProcessMonitor?) that you can use to monitor attempts > to load DLLs? What an amazing little tool. Thank you! I found it here - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon I was able to configure it to just monitor prunsrv.exe, and then I just tried to start my service from the Windows Service Manager. It generated a lot of information, but once I dug through it, it was very obvious what was happening. The short of it, is that there is no problem with Procrun. The long of it... The problem was that we ship two versions of the DLL native library with the application, and each of those is wrapped inside a distinct jar file, e.g. ourlib.jar and ourlib-debug.jar. The debug version is there should we have any problems and we need to enable it to get further information. When starting our application standalone (i.e. NOT as a service), it uses Codehaus's AppAssembler Booter which tightly controls what is on the classpath from a list inside an XML file. The debug version of the Jar is NOT on that list. For running the application as a service we had set `--Classpath="C:/Program Files/FusionDB Server/lib/*"` to prunsrv when we installed the service. When we subsequently started the application via the Service, both production and debug versions of the ourlib jar, were loaded to the classpath. As those ourlib jars contain the same package and class names, we can't guess which will be chosen when we ask for one. At runtime Java was deciding to use the debug version and not the production version. The debug version of the DLL native library has an additional dependency on MSVCP140D.dll. The MSVCP140D.dll (the 'D' is for debug) is not part of the standard Microsoft Visual C++ redistributable package that is often installed, it is only available as part of Visual Studio! This also explains why we did not see this issue on our development machines! See - https://docs.microsoft.com/en-us/cpp/windows/preparing-a-test-machine-to-run-a-debug-executable?view=vs-2019 Whilst the problem was ultimately with our use of the classpath... this one was a tricky one to diagnise and so I have included the details here in-case anyone else hits a similar issue with Procrun in future. p.s. Thanks for all the help Mark :-) Cheers Adam. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [daemon] Procrun UnsatisfiedLinkError with JNI project
Hello, You can create a new service with any binary you want to run. This will not answer service control commands, so it will fail to respond, but the binary is started and can do your testing. You just won't get desktop access. (This is similar to what psexec does). I would suspect context specific things like PATH or generally environment, registry, possibly certificates and of course access to UNC or mounted directories (and desktop session) be affected by local system. Gruss Bernd -- http://bernd.eckenfels.net Von: Adam Retter Gesendet: Tuesday, May 12, 2020 4:15:32 PM An: Commons Users List Betreff: Re: [daemon] Procrun UnsatisfiedLinkError with JNI project Thanks for your response Mark, further comments inline below - > It shouldn't. > > Maybe a permissions problem? Although running as LocalService is should > be fine. So I am using the `--ServiceUser=LocalSystem` flag - to run under the LocalSystem account. (i.e. NOT `NT Authority\Local Service`). > I guess check the obvious. Does the dll exist where the app is looking? It does exist yes. I have a working theory in fact that it loads the DLL, but it is the dependencies of that DLL (which will be various Windows system DLL's) that it can't load. > Can LocalSystem read that file etc. Do you know - Is there someway that I can directly execute code under "LocalSystem" to see if I can reproduce the problem outside of Procrun? -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [daemon] Procrun UnsatisfiedLinkError with JNI project
On 12/05/2020 15:15, Adam Retter wrote: > Thanks for your response Mark, further comments inline below - > >> It shouldn't. >> >> Maybe a permissions problem? Although running as LocalService is should >> be fine. > > So I am using the `--ServiceUser=LocalSystem` flag - to run under the > LocalSystem account. (i.e. NOT `NT Authority\Local Service`). Sorry. I knew that and still typed it wrong. LocalSystem is a member of the local administrators group so it should be able to read the file. Maybe try running the service as the same user as the one you use when running from the command line. That should help narrow down what is going on. >> I guess check the obvious. Does the dll exist where the app is looking? > > It does exist yes. I have a working theory in fact that it loads the > DLL, but it is the dependencies of that DLL (which will be various > Windows system DLL's) that it can't load. Is there a tool (ProcessMonitor?) that you can use to monitor attempts to load DLLs? >> Can LocalSystem read that file etc. > > Do you know - Is there someway that I can directly execute code under > "LocalSystem" to see if I can reproduce the problem outside of > Procrun? I'd go the other way and run procrun under the user you know works on the command line. Mark - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [daemon] Procrun UnsatisfiedLinkError with JNI project
Thanks for your response Mark, further comments inline below - > It shouldn't. > > Maybe a permissions problem? Although running as LocalService is should > be fine. So I am using the `--ServiceUser=LocalSystem` flag - to run under the LocalSystem account. (i.e. NOT `NT Authority\Local Service`). > I guess check the obvious. Does the dll exist where the app is looking? It does exist yes. I have a working theory in fact that it loads the DLL, but it is the dependencies of that DLL (which will be various Windows system DLL's) that it can't load. > Can LocalSystem read that file etc. Do you know - Is there someway that I can directly execute code under "LocalSystem" to see if I can reproduce the problem outside of Procrun? -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [daemon] Procrun UnsatisfiedLinkError with JNI project
On 12/05/2020 11:40, Adam Retter wrote: > Hi there, > > I have a Java project which is using JNI to load a native library. I > would like to install it as a Windows service. > > To install it I am running: > > prunsrv.exe install FusionDB-Server --DisplayName=FusionDB-Server > --Description="FusionDB Server" --StdError=auto --StdOutput=auto > --LogPath="C:\Users\aretter\AppData\Roaming\FusionDB Server\logs" > --LogPrefix=service --PidFile=service.pid --Startup=auto > --ServiceUser=LocalSystem --Jvm="C:\Program > Files\BellSoft\LibericaJRE-11-Full\bin\client\jvm.dll" > --Classpath="C:/Program Files/FusionDB Server/lib/*" --JvmMs=128m > --StartMode=jvm --StartClass=org.exist.service.ExistDbDaemon > --StartMethod=start --StopMode=jvm > --StopClass=org.exist.service.ExistDbDaemon --StopMethod=stop > --JvmOptions="-Dfile.encoding=UTF-8;-Dlog4j.configurationFile=C:\Program > Files\FusionDB Server/etc/log4j2.xml;-Djetty.home=C:\Program > Files\FusionDB Server;-Dexist.jetty.config=C:\Program Files\FusionDB > Server/etc/jetty/standard.enabled-jetty-configs;-Djetty.git.hash=ab228fde9e55e9164c738d7fa121f8ac5acd51c9;-Dexist.home=C:\Program > Files\FusionDB Server;-Dexist.configurationFile=C:\Program > Files\FusionDB Server/etc/conf.xml" --StartParams="C:\Program > Files\FusionDB Server\etc\conf.xml" --JvmMx=4224m" > > > However, when I then try and start the Service for my application, my > application raises an error when it tries to load the native library > via Java's System.load(absolutePathToLib) and fails to start up: > > Caused by: java.lang.UnsatisfiedLinkError: > C:\Windows\Temp\librocksdbjni18005926251924699790.dll: Can't find > dependent libraries > at java.lang.ClassLoader$NativeLibrary.load0(Native Method) ~[?:?] > at java.lang.ClassLoader$NativeLibrary.load(Unknown Source) ~[?:?] > at java.lang.ClassLoader$NativeLibrary.loadLibrary(Unknown Source) ~[?:?] > at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:?] > at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:?] > at java.lang.Runtime.load0(Unknown Source) ~[?:?] > at java.lang.System.load(Unknown Source) ~[?:?] > at > org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:79) > ~[rocksdbjni-202004011324-patched-debug.jar:?] > > If I run my application directly, i.e. not via the Service, then it is > able to correctly load the native library and start's up ok. > > I have tested this on both Windows Server 2012 and 2019 with both JRE > 8 and JRE 11. > > Are there limitations on loading native libraries (or their > dependencies) from a Java Application started from a Procrun service? > I am also using StartMode "jvm" perhaps that has some limitation in this area? It shouldn't. Maybe a permissions problem? Although running as LocalService is should be fine. I guess check the obvious. Does the dll exist where the app is looking? Can LocalSystem read that file etc. Mark - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
[daemon] Procrun UnsatisfiedLinkError with JNI project
Hi there, I have a Java project which is using JNI to load a native library. I would like to install it as a Windows service. To install it I am running: prunsrv.exe install FusionDB-Server --DisplayName=FusionDB-Server --Description="FusionDB Server" --StdError=auto --StdOutput=auto --LogPath="C:\Users\aretter\AppData\Roaming\FusionDB Server\logs" --LogPrefix=service --PidFile=service.pid --Startup=auto --ServiceUser=LocalSystem --Jvm="C:\Program Files\BellSoft\LibericaJRE-11-Full\bin\client\jvm.dll" --Classpath="C:/Program Files/FusionDB Server/lib/*" --JvmMs=128m --StartMode=jvm --StartClass=org.exist.service.ExistDbDaemon --StartMethod=start --StopMode=jvm --StopClass=org.exist.service.ExistDbDaemon --StopMethod=stop --JvmOptions="-Dfile.encoding=UTF-8;-Dlog4j.configurationFile=C:\Program Files\FusionDB Server/etc/log4j2.xml;-Djetty.home=C:\Program Files\FusionDB Server;-Dexist.jetty.config=C:\Program Files\FusionDB Server/etc/jetty/standard.enabled-jetty-configs;-Djetty.git.hash=ab228fde9e55e9164c738d7fa121f8ac5acd51c9;-Dexist.home=C:\Program Files\FusionDB Server;-Dexist.configurationFile=C:\Program Files\FusionDB Server/etc/conf.xml" --StartParams="C:\Program Files\FusionDB Server\etc\conf.xml" --JvmMx=4224m" However, when I then try and start the Service for my application, my application raises an error when it tries to load the native library via Java's System.load(absolutePathToLib) and fails to start up: Caused by: java.lang.UnsatisfiedLinkError: C:\Windows\Temp\librocksdbjni18005926251924699790.dll: Can't find dependent libraries at java.lang.ClassLoader$NativeLibrary.load0(Native Method) ~[?:?] at java.lang.ClassLoader$NativeLibrary.load(Unknown Source) ~[?:?] at java.lang.ClassLoader$NativeLibrary.loadLibrary(Unknown Source) ~[?:?] at java.lang.ClassLoader.loadLibrary0(Unknown Source) ~[?:?] at java.lang.ClassLoader.loadLibrary(Unknown Source) ~[?:?] at java.lang.Runtime.load0(Unknown Source) ~[?:?] at java.lang.System.load(Unknown Source) ~[?:?] at org.rocksdb.NativeLibraryLoader.loadLibraryFromJar(NativeLibraryLoader.java:79) ~[rocksdbjni-202004011324-patched-debug.jar:?] If I run my application directly, i.e. not via the Service, then it is able to correctly load the native library and start's up ok. I have tested this on both Windows Server 2012 and 2019 with both JRE 8 and JRE 11. Are there limitations on loading native libraries (or their dependencies) from a Java Application started from a Procrun service? I am also using StartMode "jvm" perhaps that has some limitation in this area? Thanks Adam. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
