Frequently Asked Questions
JConsole and Remote Management

JConsole and JMX Remote Management

1. I run JConsole on Windows. Why does the Local tab in Connect dialog not list any Java processes?
2. JDK 5 jconsole and jps commands do not work if your username contains '_' (underscore) on Windows. JConsole is unable to find your Java processes.
3. How to secure the password file on Windows systems?
4. JConsole fails to connect to an application remotely or locally running on the same machine using the Remote Tab. However, it works when connecting to it using the Local Tab on the same machine.
5. I am having problem using JConsole to connect to a JVM running on Linux. Connecting to JVM running on Windows and Solaris works fine.
6. My application has remote management enabled with SSL. How to setup JConsole to connect to my application?
7. How to export the remote objects for the RMI connector on a given port different than the port being used to bind the RMIConnectorServer to the RMIRegistry?

SNMP Based Management

1. Where is the standard MIB for SNMP management of the Java virtual machine? What version of SNMP protocol does it require?
2. I'm not able to see all objects the JVM MIB tree. For example, the jvmMemoryHeapUsed OID is missing. Is it a known problem?
3. I'm having trouble starting the SNMP feature in J2SE 5.0 for my JVM. The argument makes it in the java environment via pargs PID. But a netstat -na | grep PORT doesn't show anything. What am I doing wrong?

JConsole and JMX Remote Management

1. I run JConsole on Windows. Why does the Local tab in Connect dialog not list any Java process?

   The problem is most likely that your default Windows temporary directory is on a FAT file system. If your TMP file system is NTFS and JConsole does not show your processes, check your username as described in FAQ #2.

   For security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports setting permissions on files and directories (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls.

   A potential workaround for this issue:
   Set the TMP environment variable to refer to a directory on an NTFS file system, or any file system that supports setting permissions on files and directories before you run your application with local or remote management enabled. Note that this file system should be local to the machine. Setting this option for target applications is application specific. To set this variable in a command prompt or in a batch script, simply enter the following:

   set TMP=path

   The environment variable can be set globally by adding it to the list of environment variables in the System Properties (Control Panel->System, select the "Advanced" tab and click on the "Environment Variables" button). Through this interface, you can choose to set the variable for all processes run by the current user or globally as a system variable for all processes run by the system.

2. JDK 5 jconsole and jps commands do not work if your username contains '_' (underscore) on Windows. JConsole is unable to find your Java processes.

   It is a known problem in JDK 5 that jconsole and jps commands do not work on Windows if your username contains '_' (underscore). Bug 6301562 will be fixed in a future release.

3. How to secure the password file on Windows systems?

   Please see the "How to secure password files on Windows systems" document for details.

4. JConsole fails to connect to an application remotely or locally running on the same machine using the Remote Tab. However, it works when connecting to it using the Local Tab on the same machine.

   It is most likely a configuration problem. First, make sure your application was started with remote management enabled. (See details from the "Monitoring and Management using JMX" document.) Second, check if SSL is enabled in the management properties to enable remote management and if it is configured properly.

   SSL is enabled by default when the remote management is enabled. You can disable SSL by setting com.sun.management.jmxremote.ssl property to false. If your application is not set up with SSL properly but SSL is enabled for remote management, JConsole will fail to connect to the application. Please see "Using SSL" section in the "Monitoring and Management Using JMX" document for information about using SSL for remote management.

   If the connection failure problem occurs only when your application runs on Linux, please see FAQ #5.

5. I am having problem using JConsole to connect to a JVM running on Linux. Connecting to JVM running on Windows and Solaris works fine.

   This is most likely a configuration problem on the Linux machine or the management properties specified to run the application. Please also see FAQ #4 about using SSL.

   You should check the following:

   • Check if the hostname correctly resolves to the host address.

     Run "hostname -i" command. If it reports 127.0.0.1, JConsole would not be able to connect to the JVM running on that Linux machine. To fix this issue, edit /etc/hosts so that the hostname resolves to the host address.

   • Check if the Linux machine is configured to accept packets from the host where JConsole runs on to connect to the application.

     Packet filtering is built in the Linux kernel. You can run "/sbin/iptables --list" to determine if an external client is allowed to connect to the JMX agent created for remote management. You can use the following command to add a rule to allow an external client such as JConsole to connect:

     /usr/sbin/iptables -I INPUT -s jconsole-host -p tcp --destination-port jmxremote-port -j ACCEPT

     where jconsole-host is either the hostname or the host address on which JConsole runs on and jmxremote-port is the port number set for com.sun.management.jmxremote.port for remote management.

6. My application has remote management enabled with SSL. How to setup JConsole to connect to my application?

   When you enable the application for remote management with SSL, you have set up a digital certificate on the system where the JMX agent (MBean server) is running and configured SSL properly.

   Assuming you created a keystore as described in the JSSE Guide and started your application (Server) as follows:

   % java -Djavax.net.ssl.keyStore=keystore \
     -Djavax.net.ssl.keyStorePassword=password Server
   
   

   To connect to this application, you need to run jconsole as follows:

   % jconsole -J-Djavax.net.ssl.trustStore=truststore \
     -J-Djavax.net.ssl.trustStorePassword=trustword
   
   

   The above configuration authenticates the server only. If client authentication is set up, you will need to provide a similar keystore for the JConsole's keys, and an appropriate truststore for the application.

7. How to export the remote objects for the RMI connector on a given port different than the port being used to bind the RMIConnectorServer to the RMIRegistry?

   The com.sun.management.jmxremote.port management property specifies the port number through which you want to enable JMX/RMI connections. It is the port number for binding RMIConnectionServer to the RMIRegistry. To export the remote objects (RMIConnection and RMIServer) on a given port other than the one for RMIRegistry, you can create your own RMI connector server programmatically as follows:

   JMXServiceURL url = new JMXServiceURL("service:jmx:rmi://localhost:" + port1 + "/jndi/rmi://localhost:" + port2 + "/server");

   where port1 is the port number on which the RMIServer and RMIConnection remote objects are exported and port2 is the port number for binding the RMIConnectorServer to the RMIRegistry.

SNMP Based Management

1. Where can I find the standard MIB for SNMP management of the Java virtual machine? What version of SNMP protocol does it require?

   The standard MIB for the Java virtual machine can be found at: http://java.sun.com/j2se/1.5.0/docs/guide/management/JVM-MANAGEMENT-MIB.mib. Some objects exposed in the JVM MIB are 64-bit quantities. To see these objects, you need to use the SNMP v2 protocol. If you can walk the JVM MIB using SNMP v1 protocol, the 64-bit objects are skipped.

2. I'm not able to see all objects the JVM MIB tree. For example, the jvmMemoryHeapUsed OID is missing. Is it a known problem?

   The JVM MIB includes 64-bit objects which require to use the SNMP v2 protocol. All the 64-bit objects are skipped if you walk the JVM MIB using SNMP v1.

3. I'm having trouble getting the SNMP feature in J2SE 5.0 to start for my JVM. The argument makes it into the Java environment via pargs PID, but a netstat -na | grep PORT doesn't show anything. What am I doing wrong?

   This problem could be caused by one of the following factors:

   • The ACL file is not found, not readable, or does not have the appropriate permissions (although you should be seeing some warnings in this case).
   • The port you are trying to bind to is already in use (you should also see an error in this case).
   • The management.properties file (or ACL file) which is used is not the one that you intended. For example, if you misspelled the property when you invoked it, the JVM will not recognize it and will use its own management.properties file instead.
   • There is a host address mismatch (0.0.0.0 vs localhost vs hostname). By default you can only receive UDP packets that come from the loopback interface, unless you explicitly bind to the 0.0.0.0 or to the actual IP address (see NOTE below).
   • The content of the ACL file is not appropriate, for example you have granted access to the loopback address, but you are using the actual host address to send packets, or conversely.
   • You are trying to walk the MIB from an OID which is already beyond the scope of the JVM-MANAGEMENT-MIB, or you are stopping the walk before the JVM-MANAGEMENT-MIB is reached. Some SNMP walk commands have an implied starting point which might already be beyond the scope of the JVM-MANAGEMENT-MIB, or have an implied stopping point which is before the JVM-MANAGEMENT-MIB.

     Make sure your snmpwalk utility starts walking at 'sun', which is 1.3.6.1.4.1.42 (otherwise known as enterprises.42), and does not stop before that subtree is exhausted. As an alternative, try to perform a simple SNMP get on the following OID: 1.3.6.1.4.1.42.2.145.3.163.1.1.4.1 (aka jvmRTName).

   Before attempting to modify the ACL file, try out a connection with SNMP ACLs disabled, by using the following option:

   -Dcom.sun.management.snmp.acl=false

   Once this works, you can try to set up the ACL configuration.

   NOTE: If you want to be able to receive packets that come both from the loopback interface (127.0.0.1=localhost) and the actual host IP (x.y.z.w=hostname) you need to bind to 0.0.0.0 (com.sun.management.snmp.interface=0.0.0.0). See the com.sun.management.snmp.interface in management.properties.

   You must then configure the ACL file to accept both addresses (or disable the ACL file completely).