We Keep Coding

LD_LIBRARY_PATH cleared when logging in through xrdp

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.

Can VisualVM monitoring apps running on JRE

as the headline mentioned: is it possible to connect VisualVM to an remote application running on JRE instead of JDK ?
And yes, the VisualVM itself runs on JDK !
Kind regards
Dominik

VisualVM connects to a running Java Virtual Machine (JVM).
And this JVM is contained both in the JDK and the JRE.
In fact, the JDK is a JRE with additional tools and items to allow creating Java programs. If you only want to run them, you only need a JDK.
So yes, you can connect to a JRE-only install.

VisualVM unable to sampler memory

I have a tomcat instance with the JMXRemote parameter configured. The local VisualVM is able to get a sampler on CPU, however, not for Memory. The memory button is grayed out with a summary saying: "Memory sampling: Not available. Cannot connect to target application. Make sure the application is running on a supported JDK 6 or JDK 7"
JMXRemote parameter:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Tomcat JDK version:
JDK1.6.0.30
VisualVM version:
Version: 1.6.0_30 (Build 1320-110325); platform 110131-9c8b3bfb3a1e
System: Windows Server 2008 R2 (6.1) , amd64 64bit
Java: 1.6.0_30; Java HotSpot(TM) 64-Bit Server VM (20.5-b03, mixed mode)
Vendor: Sun Microsystems Inc., http://java.sun.com/
Environment: Cp1252; en_US (visualvm)
Userdir: C:\Users\Administrator\AppData\Roaming\.visualvm\7
Clusters: C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\platform
C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\visualvm
C:\Program Files\Java\jdk1.6.0_30\lib\visualvm\profiler
Tomcat version:
Tomcat 6.0.32
I am running both the VisualVM and Tomcat at win server 2008. Anything i did wrong?

I had the same problem before.
You must have downloaded the version from jvisualvm homepage, right?
Don't do it!
If you use new jdk 1.7, VisualVM is already packaged in your jdk folder.
Use this version, you will not have any problem with memory sample.

This blog post leads me to believe that the temp directories of JVisualVM and Tomcat need to be the same for memory sampling to work. One of the comments on the post:
the temp directory must be set to the one used by JVisualVM, which can be discovered from the VisualVM system properties tab (java.io.tmpdir). Once I set the CATALINA_TMPDIR directory properly, this worked beautifully.

I've just run into this same issue and the answers above solved my problem but it took me a while to figure out how. Just in case anyone else is still having trouble and ends up this far down the thread, I was using the JDK that is part of the weblogic server configured through Eclipse and not the JDK that I installed seperately. I'm still a junior programmer and I wasn't putting 2 and 2 together until I started looking through my eclipse settings and verified my Installed JREs.
Ran the jvisualvm.exe from the weblogic jdk and all worked.

I would check the version of VisualVM is exactly the same as the JVM.
VisualVM is very version specific. I assume its still under fairly rapid development.
(Re posted as an answer as it may be the solution)

I've faced similar issues with JVisualVM, I've even asked a question about it here
A couple of insights/advices:
So, in order to sample memory you don't need jmx options.
I would double check whether you have 64 bit jvms installed along with 32 bit jdks on the same machine (even if they're not running and all the environment vars defined properly), I've read somewhere that sometimes it drives the JVisualVM crazy :) (yes I know it doesn't sound reasonable to us, java developers)
If it doesn't work, just uninstall all jdks that you have and install only 1 that you need. It can solve the issue.
I hope it will help you to resolve the issue, after all like Peter said these things are new and evolving

Here is my solution for similar problem: https://stackoverflow.com/a/16330238/715483
You can resolved this error by
$ ssh -Y user#remotemachine
$ wget http://java.net/projects/visualvm/downloads/download/release135/visualvm_135.zip
$ unzip visualvm_135.zip
$ cd visualvm_135/bin
$ ./visualvm
This instance of visualvm will be full featured, including memory and CPU sampling.
Read more about it here: http://shahriarinia.blogspot.com/2013/05/java-cpumemory-heap-usage-monitoring.html
http://mshahriarinia.com/

Make sure your VirtualVM/JDK is a 32-bit copy if your JRE is. If you are using Eclipse, check the selected JRE on Installed JRE's section.

And I have the same problem.
I always launched tomcat as a service and connected it with visualvm through jmx connection.
When had corrected catalina.bat:
set JAVA_OPTS=%JAVA_OPTS%
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
and launched it with startup.bat, visualvm automatically determine tomcat, and memory sampling was active.

I've got the same problem but with different envirnoment. My server was a Linux machine, the client a Windows 7 machine, but the problem is the same.
The solution was to launch the jvisualvm in the same machine and with the same user that is running the targeted application. If i run jvisualvm with other other user (ex: root) the memory button became gray.

Firstly, JMX should be enabled. Add the linked command line environment variables necessary to activate JMX if you haven't.
The environment variable CATALINA_TMPDIR should be set to match the JVisualVM as seen in the "System properties" tab of the Local > VisualVM. You can open this by double clicking on the "VisualVM" labeled entry in the Applications pane on the left.
Environment variables can be set by searching for environment, "edit environment variables for your account". New... > Enter a name and value.
If you would like the temporary directory of VisualVM to be somewhere else, you'll have to launch VisualVM from the command line and add an argument.
C:\Program Files\Java\jdk1.8.0_65\bin>jvisualvm.exe -J-Djava.io.tmpdir=C:\Users\You\Temp

How do I monitor Tomcat6 with JVisualvm in Ubuntu Linux?

I'm trying to set up JVisualVm to monitor a Tomcat 6 instance (running on Ubuntu Server 10.04 LTS). I've seen other questions, but none of them directly answer my problem. I try to connect to Tomcat with JVisualvm and it comes back with a "Cannot connect" error - but there are TCP connections being made to the server; the server drops the connection after a short burst of traffic.
I have already added this to /etc/default/tomcat6 and restarted tomcat6
# This enables JMX in order to permit VisualVM to profile the JVM.
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
I started rmiregistry using default settings:
rmiregistry &
I haven't started jstatd; installing it on the server requires the full JDK which requires X libraries. I'm not about to install X just to get one single binary.
I wonder if not running jstatd would have something to do with it; I was of the impression that I needed neither RMI nor jstatd, as long as I could use JMX directly via the JMX port.
There is no firewall in between the server and the JVisualvm client, and the iptables host firewall is open. Using jconsole results in the same error.
Running JVisualVM against the local Ubuntu 10.04 machine (by using its IP address and JMX port) and adding a JMX instance works fine - and I'm running neither rmiregistry nor jstatd - though the monitor shows RMI threads running.
Question: What must I do (either on the server or the client) in order to be able to monitor Tomcat (and other Java programs) via JMX with JVisualVM?
Thanks in advance.

If there is no firewall, try to set java.rmi.server.hostname system property for your Tomcat. Add this to your Tomcat's JAVA_OPTS:
-Djava.rmi.server.hostname=<IP address of Ubuntu Server>
You don't need to start rmiregistry and you don't need to run jstatd to be able to monitor your Tomcat remotely.

For the record: jstatd does not require X libraries, it only depends on them via some other recommended package. You can make aptitude or apt-get skip installation of recommended packages and have jstatd installed without any X11 libraries.
For aptitude, go into options ➞ preferences ➞ Install recommended packages automatically. For apt-get, see this question on askubuntu.

VisualVM "not supported for this JVM" on all local applications?

I have already spent a long time to load and test my application, now I need to profile it. But unluckily, the VisualVM always says "not supported for this JVM" on my local applications?
The applications were started on the same JVM with VisualVM.

I found out that (at least under Windows) one can easily write small batch files to run VisualVM in combination with specific JVMs, which is important for me, since I have installed the 32bit JDK alongside with the 64bit JDK (I need both, so this is sensible for me).
I have created two batch files in the folder "S:\applications\visualvm\bin\":
run_32.bat:
#echo off
START "VisualVM 32" visualvm.exe --jdkhome "C:\Program Files (x86)\Java\jdk1.7.0_07"
run_64.bat:
#echo off
START "VisualVM 64" visualvm.exe --jdkhome "C:\Program Files\Java\jdk1.7.0_07"
Obviously, all paths may differ on your system, but the general idea should still work correctly (on all 64bit versions of Windows). The benefit is that I can use the 32bit batch file when I want to use VisualVM in combination with Java applications that run on the 32bit JVM, and so on for 64bit.
The "start" command has the only benefit that the batch file launches the application without waiting for it to finish, so the command prompt window closes immediately. This is not a feature of VisualVM, but of the Windows batch file interpreter.

In my case, even with the JVMs matching (both 64-Bit), the only way to get things working was sending the argument -Dcom.sun.management.jmxremote to the JVM to be monitored. That also works if you are having problems to connect via Java Mission Control (JMC).
According to JMX's documentation, this what the argument does:
Setting this property registered the Java VM platform's MBeans and published the Remote Method Invocation (RMI) connector via a private interface to allow JMX client applications to monitor a local Java platform, that is, a Java VM running on the same machine as the JMX client.
This was supposed to be enabled automatically, but for some reason it wasn't on my Linux.

VisualVM needs to be run with the same JVM - at least Java 6 with the same 32-bit/64-bit size - as the program to be profiled. (You also need to be the same user, but then this message does not apply).
I would be triple-check that it was the exact same JVM in your situation.

On Linux:
Make sure that your /etc/hosts correctly references the effective ip address of your "hostname"
It appears that a discrepancy here totally confuses the poor jvisualvm and its programmers.

I too got the same problem for local tomcat, I search for solutions for stackoverflow. after some serious debugging, I figured out that VisualGC don't have permissions to get GC informations from tool.jar file.
by links
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstatd.html#SECURITY
https://stackoverflow.com/a/42107355/3876619
I following steps to solve the issue
1) Create a permission file
vim /tmp/tools.policy
Add
grant codebase "file:${java.home}/../lib/tools.jar" {
permission java.security.AllPermission;
};
save it
2) Now add /tmp/tools.policy to JVM startup parameters
-Djava.security.policy=/tmp/tools.policy
3) Run jvisualVm with sudo

An issue that I just found, thanks to the hint from #user3356656, is that if you start the program while your machine is on one IP, and then try to connect while it is on a different IP, it will fail.

I also met this issue. My case is that on linux, I started tomcat with tomcat_user but I run jvisualvm with root user. It works after I start tomcat with root user.

I was having the problem having of visualvm detect my local tomcat installation on Windows 7. I could connect manually, but then things like memory snapshots and visualgc plugin were not enabled. I confirmed that I was using same JVM version, temp file permissions, etc. Didn't work. Then I found that starting visualvm first, and then tomcat, solved the problem.

As you can see, you are running VisualVM on 32bit JVM
You don't need to unistall 32bit JVM. Just tell VisualVM to use tour 64bit JVM.
If you want to change it permanently, you can edit
in visualvm_13\etc\visualvm.conf and specify the path of jvm here

My problem was JVM optimizations - -XX:+PerfDisableSharedMem flag will break VisualGC. This is apparent if jps will not show your app in the listing.

I can reproduce next behaviour.
I have a java application with right-click menu item to open jvisualvm.
I'm running this java application as standalone setup from a bat file.
It means I modify %path% and other needed environment variables like JDK
accordingly to form my environment.
The BAT that starts application is marked running as non-admin. Environment points to a 64-bit JDK.
Then I start other java application as admin. VM lives from the to same 64-bit JDK-source.
Then I start jvisualvm from first app with the right click ie.as non-admin.
I can see the app in jvisualvm ‘Applications list’ but clickin ‘System properties’ gives error. Message is “Not supported for this JVM”.
JVM arguments are exposed.
Solution is like in some other previous comments:
Starting my right-click jvisualvm-starter as admin I can see also "system properties" .
Certainly if JDKs would be 32-bit and other 64-bit it would not work. been there.
I thought this notion needs to be added here.

In my case, the application was running with admin permissions. So, visualVM also need to be running as admin.

I have changed name to my Windows User and set it all lowercase, restarted my PC and it all works now.

For me, the reason is that I have run the "jstatd" with a different user with the JVM process. I have a special user in the linux to start the JVM thread(it is a tomcat), but I start the jstatd process with root. If you use root to run jps, you cannot see any information of the JVM threads belonging to other users. That is the trouble.
I killed the "jstatd" process started by root, su to the owner of the JVM process, and restart the "jstatd" process and everything wokrs fine now.