Background:
I am currently working in a Linux Virtual Machine on some Java plugins that I install into Eclipse by placing them into the /opt/eclipse/dropins folder. My plugins need to support both CentOS 6 and CentOS 7 VMs (shouldn't be a big deal since they are written in Java and both flavors of CentOS have Java 1.8.0 installed). My plugins build and install just fine on both OSs. I see them in Eclipse and can interact with them as expected.
The VMs I need to support can either be local to my machine (opened with VMWare Player/Workstation) or hosted on a cloud server. We use Windows Remote Desktop to get into the cloud VMs through xrdp on the Linux server.
Problem:
One of my plugins needs nddsjava.so from /opt/rti_connext_dds-5.2.3/lib/x64Linux3gcc4.8.2.
On both local VMs (CentOS 6 and 7), I can just set the LD_LIBRARY_PATH in an /etc/profile.d script so that any user that logs in can get the path to the required C++ library.
On CentOS 7 cloud VMs, however, when this plugin is invoked, I get java.lang.UnsatisfiedLinkError: no nddsjava in java.library.path. This happens only when opening Eclipse via the Linux menus. If I open a terminal and start Eclipse from there, the plugin can find the C++ library (because my LD_LIBRARY_PATH is set in my /bin/bash terminal). I did a little digging and found out that running chmod g-s /usr/bin/ssh-agent fixes the issue when opening Eclipse from the Linux menus (yes I understand that the chmod opens a security vulnerability. I am willing to look past this).
On CentOS 6 cloud VMs, I have never gotten the plugin to find the C++ library. LD_LIBRARY_PATH seems to get wiped when signing in through xrdp and for whatever reason, CentOS 6 appears to be explicitly not sourcing any of the profile scripts in the main top-level gnome-session process, which means other processes spawned from the GUI will not have LD_LIBRARY_PATH either.
I have also tried adding -Djava.library.path to my eclipse.ini file with no luck. It will fail on the next C++ library needed even though it lives in the same directory: java.lang.UnsatisfiedLinkError: /opt/rti_connext_dds-5.2.3/lib/x64Linux3gcc4.8.2/libnddsjava.so: libnddsc.so: cannot open shared object file: No such file or directory
Question:
Is there a single place that I can set my LD_LIBRARY_PATH for all flavors of Linux I am attempting to support (local CentOS 6, xrdp CentOS 6, local CentOS 7, and xrdp CentOS 7)?
Note: When I say cloud VM below, I mean server hosted VM in which I Windows-Remote-Desktopped into via xrdp.
This answer from server fault worked for me in the CentOS 6 cloud VM. The CentOS 7 cloud VM did not have the startwm.sh script in /etc/xrdp. Instead, it lived in /usr/libexec/xrdp and did not contain the xinitrc lines (referenced in the server fault link) causing the issue in the CentOS 6 cloud VM. Something else must be wiping the LD_LIBRARY_PATH variable in the CentOS 7 cloud VM, so I still needed to perform chmod g-s /usr/bin/ssh-agent to allow my /etc/profile.d script to be invoked on startup.
Related
I compiled a Servlet with java 15 and tried to run it with Tomcat 10 but got the error:
"java.lang.UnsupportedClassVersionError: Servlet1 has been compiled by a more recent version of the Java Runtime"
Looking at the Tomcat Properties I noticed Tomcat uses Java 8 that is installed also on my PC.
So I went to the Tomcat Properties under the Java tab and put down jdk-15.0.1\bin\jvm.dll
-> Tomcat didn't start anymore.
I noticed that in the same properties under the Java tab, there is "Java Classpath" but it's value was
Tomcat-Dir\bin\bootstrap.jar (I think). Then I changed this to jdk-15.0.1\bin (and variations thereof).
Now to my problem - Tomcat doesn't start anymore "ClassNotFoundException ... Bootstrap" I can change back the path to the JVM by checking "Use default", but I don't remember exactly the path under "Java Classpath". Can someone tell me what the default value needs to be here for Tomcat10. I would like to at least be able to start Tomcat again.
I'm talking about this Tab in the Tomcat properties
The problem you are describing (immediate service start failure, nothing in Tomcat's logs and a short line in commons-daemon.log) happens when there is a mismatch between the architecture of the Procrun service application (installed as bin\tomcat10.exe in your Tomcat installation) and the architecture of the jvm.dll: a 32-bit executable cannot load a 64-bit library and viceversa.
You can confirm it with tomcat10.exe version (works only in an administrator cmd)) and java -version.
To solve this you need to download the complete Apache Commons Daemon distribution for Windows (cf. download area) and replace tomcat10.exe with the appropriate prunsrv.exe executable (there are two versions in the zip archive).
Regarding which libraries should be in Tomcat's classpath, you just need bin\bootstrap.jar and bin\tomcat-juli.jar in your server's installation folder.
Remark: The Windows MSI installer for Tomcat contains both prunsrv.exe versions, but installs only one depending on the architecture of the Java executable you choose during installation. Probably you have a 32-bit Java 8 and 64-bit Java 15. For a long time the java.com page automatically proposed the 32-bit version of Java.
I have a Windows virtual machine with OpenJDK 13 installed that I would like to setup as a Jenkins node/agent.
When I create the node configuration using the Jenkins UI and select Launch Method: Launch Agent by connecting it to the master it provides a link to download slave-agent.jnlp
On a system with the original jdk/jre older than version 9, which contains java web start, if I run that jnlp file, it brings up a window with a menu that includes an option File - Install as A Service
However, as OpenJDK (and I believe any JRE/JDK versions greater than 8) do NOT contain Java Web Start, I cannot seem to gain access to that option.
I am able to successfully run java -jar agent.jar -jnlpUrl https://jenkinsserver/blah/slave-agent.jnlp -secret blah -workDir "somedirectory" and have the node register with Jenkins, but it is not running as a service.
I had an older agent that was still using old version of JRE, so I looked at its Jenkins service configuration and unfortunately it seems to be relying on executable(s), .config file(s), and xml file(s), which I cannot determine the source of, beyond they must be created when running the "Install as a service" instructions from slave-agent.jnlp
I also attempted to use IcedTea-Web which is apparently supposed to be a Java Web Start replacement, but I've had no success.
Can anyone tell me how to setup a Windows machine running OpenJDK as a Jenkins node/agent with the Jenkins node/agent components running as a Windows service?
I had a similar issue and now I use NSSM.
Download NSSM
Open a cmd and install the service (I used JenkinsService as Servicename):
<path to nssm.exe>\nssm install <Servicename>
Insert the path to the jdk to the field Path
add the rest to the field Arguments:
-jar agent.jar -jnlpUrl https://jenkinsserver/blah/slave-agent.jnlp -secret blah -workDir "somedirectory"
Click on install the service
Now you can check the new service JenkinsService in the windows service manager. As soon as it's running you can check the connection to the master.
If you want to setup a Java base application as a service, I believe the best option would be to use Procrun from Apache. It is the exact method that Tomcat uses.
I have developed a Java application that references a third party library. Let's call it SW_Lib and the sub folder containing relevant DLL and Lib files SW_Lib\lib.
The application works fine on Windows 7 Professional. I have used Windows 7 Professional for development and testing.
I wish to run the application in production on a Windows 2008 Server Standard (64 bit) operating system. And this is where I am encountering problems. While the application compiles fine, it complains at run time due to its inability to dynamically link the SW_Lib libraries.
In Windows 7 workstations, I have set the Path environment variable correctly to reference SW_Lib libraries. For my example, it simply says C:\Java\SW_Lib\lib. This works perfectly in the Windows 7 workstations.
In the Windows 2008 Server, I set the Path environment variable in exactly the same way and made sure that all directory structures are the same in both Windows 7 and Windows 2008 Server.
But my application simply cannot reference a particular DLL in SW_Lib\lib folder at run time in the server. I have looked at the internet for clues and it seems that setting the Path environment variable correctly should prevent me from having this issue, except that this is currently not working in Windows 2008 server.
I am using JDK 1.8 and am wondering if there are any backward compatibility issues with that and Windows 2008 Server. Many thanks.
Are you talking about native libraries or jars?
If native libraries, have you checked java.library.path System property in both environments?
Are both environments running same 32/64 bit architecture?
I use;
Windows 7 64 bit,
JAVA_HOME= JDK1.7 64 bit,
Tomcat-7 64 bit version
When I start tomcat from commandline it works ok, but when I use it within IntelliJ I get this error;
java.lang.UnsatisfiedLinkError: tcnative-1 (.\tcnative-1.dll is not a valid Win32 application.
I also point to an IBM 32bit JDK1.6 from IntelliJ in project settings, but this could not be a problem since this setup works on some other collegae's computers
I have read similar questions here, but none of them offers a solution for my case, any ideas, how can I fix this?
Here is a link which describes the problem :
Cause:
You get this message when you start Tomcat. Tomcat is looking for a shared object call tcnative (dll or so depending on the platform). If it doesn't find it, it'll revert to java libs. Either way, this shouldn't affect your application. tcnative dll is needed to address scalability in Tomcat.
Solution:
Turn down debugging level for Tomcat or
Get tcnative from http://tomcat.apache.org/native-doc/ (windows users can download the binary) and place it in your library path.
Lib path is usually: C:\Program Files\Apache Software Foundation{Apache Tomcat directory}\lib; for windows
Basically It seems that you may have an incorrect version.
Are you using multiple java on your machines if yes then try to look into environment variables for JAVA_HOME & PATH. Secondly, also paste the complete version of java and tomcat
Also run following commands at command prompt
java -version
javac -version
echo %JAVA_HOME%
And are you using MSI installer of tomcat or just a zip version of tomcat. Because in many cases MSI installer never work for some ghost reasons.
We have a Java process which we run as a Windows service (using srvany). It runs with Java 1.6 (1.6.0.23 at the moment).
In the past (Windows XP), I could connect JConsole to the processes, on Windows 7 I cannot do this anymore.
If I run jconsole <pid> I get “Invalid process id:4488”. The services are running as SYSTEM user.
If I make the service run as my desktop user (using “Log On as This Account”) the services process ID appear in JConsole, but they are grayed out and I cannot connect.
Is it impossible to dynamically connect to Java processes when they are running as a Windows 7 service?
Perhaps it is a 64bit/32bit problem, I have several applications compiled with 32bit JDK, which could not be opened with JConsole from 64bit JDK on Windows 7 64bit, after I downloaded the 32bit JDK it worked.
Others have been able to run jstack on 2008r2 which may provide some insight on how to get jconsole to connect on Windows 7. As you noted in your comment, the permissions are important. If the service and jconsole can't access the temp directory to write to the appropriate hsperf subdirectory, it won't work. What is also important is the location of the temp directory, the user the service is running, and the user that is running jconsole.
Running SysInternals psexec -s -i <jdk_home>\bin\jconsole <PID> can be used to run jconsole as Local System, the same user that I believe you are using to run your service.
My experience running jconsole from JDK 1.5 in Server 2008 as a system user was unsuccessful. With permissions that I thought should have been sufficient, I got a Could Not Open PerfMemory error. Java 1.6 may be a different story.
In light of all the challenges with running jconsole locally, you would probably have better luck setting it up to accept remote connections. You could set it up for local-only access with your firewall blocking that port from external access.
Add the following to JAVA_OPTION
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Then,
Use JConsole to connecet remote session:
localhost:8086
I am currently facing the same problem but on Windows 2003 R2 (SP2). There is on open bug in Oracle Bug database (bug id 6399729)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6399729
Also there is a work-around posted towards the end. It talks about installing java in "install" mode :-), but didn't work for me on Windows 2003 though. But your mileage may vary!!
Change Environment Variable TEMP and Tmp to a different folder that you created.
Like c:\theTemp
It might be a problem with the folder %TMP%/hsperfdata_{USER_NAME}.
In my case, it worked after I :
close all applications running over the JVM
delete the folder %TMP%/hsperfdata_{USER_NAME} (exemple: C:/Temp/hsperfdata_MyUser)
reopen JConsole (it recreates the folder)
Hope it helps. You can also take a look at this thread in Oracle community.