jstatd - Virtual Machine jstat Daemon

Synopsis
Parameters
Description
Options
Security
Remote Interface
Examples
See Also

SYNOPSIS

jstatd [ options ]

PARAMETERS

options: Command-line options. The options may be in any order. If there are redundant or contradictory options, the last option specified will take precedence.

DESCRIPTION

The jstatd tool is an RMI server application that monitors for the creation and termination of instrumented HotSpot Java virtual machines (JVMs) and provides a interface to allow remote monitoring tools to attach to JVMs running on the local host.

The jstatd server requires the presence of an RMI registry on the local host. The jstatd server will attempt to attach to the RMI registry on the default port, or on the port indicated by the -p port option. If an RMI registry is not found, one will be created within the jstatd application bound to the port indicated by the -p port option or to the default RMI registry port if -p port is omitted. Creation of an internal RMI registry can be inhibited by specifying the -nr option.

NOTE: This utility is unsupported and may or may not be available in future versions of the JDK. It is not currently available on the Windows 98 and Windows ME platforms.

OPTIONS

The jstatd command supports the following options:

-nr: Do not attempt to create an internal RMI registry within the jstatd process when an existing RMI registry is not found.
-p port: Port number where the RMI registry is expected to be found, or, if not found, created if -nr is not specified.
-n rminame: Name to which the remote RMI object is bound in the RMI registry. The default name is JStatRemoteHost. If multiple jstatd servers are started on the same host, the name of the exported RMI object for each server can be made unique by specifying this option. However, doing so will require that the unique server name be included in the monitoring client's hostid and vmid strings.
-Joption: Pass option to the java launcher called by javac. For example, -J-Xms48m sets the startup memory to 48 megabytes. It is a common convention for -J to pass options to the underlying VM executing applications written in Java.

SECURITY

The jstatd server can only monitor JVMs for which it has the appropriate native access permissions. Therefor the jstatd process must be running with the same user credentials as the target JVMs. Some user credentials, such as the root user in UNIX™ based systems, have permission to access the instrumentation exported by any JVM on the system. A jstatd process running with such credentials can monitor any JVM on the system, but introduces additional security concerns.

The jstatd server does not provide any authentication of remote clients. Therefore, running a jstatd server process exposes the instrumentation export by all JVMs for which the jstatd process has access permissions to any user on the network. This exposure may be undesireable in your environment and local security policies should be considered before starting the jstatd process, particularly in production environments or on unsecure networks.

The jstatd server installs an instance of RMISecurityPolicy if no other security manager has been installed and therefore requires a security policy file to be specified. The policy file must conform to the default policy implementation's Policy File Syntax.

The following policy file will allow the jstatd server to run without any security exceptions. This policy is less liberal then granting all permissions to all codebases, but is more liberal than a policy that grants the minimal permissions to run the jstatd server.

grant codebase "file:${java.home}/../lib/tools.jar" {
   permission java.security.AllPermission;
};

To use this policy, copy the text into a file called jstatd.all.policy and run the jstatd server as follows:

jstatd -J-Djava.security.policy=jstatd.all.policy

For sites with more restrictive security practices, it is possible to use a custom policy file to limit access to specific trusted hosts or networks, though such techniques are subject to IP addreess spoofing attacks. If your security concerns cannot be addressed with a customized policy file, then the safest action is to not run the jstatd server and use the jstat and jps tools locally.

REMOTE INTERFACE

The interface exported by the jstatd process is proprietary and is guaranteed to change. Users and developers are discouraged from writing to this interface.

EXAMPLES

Here are some examples of starting jstatd. Note that the jstatd scripts automatically start the server in the background.

Using Internal RMI Registry

This example demonstrates starting jstatd with an internal RMI registry. This example assumes that no other server is bound to the default RMI Registry port (port 1099).

jstatd -J-Djava.security.policy=all.policy

Using External RMI Registry

This example demonstrates starting jstatd with a external RMI registry.

rmiregistry&
jstatd -J-Djava.security.policy=all.policy

This example demonstrates starting jstatd with an external RMI registry server on port 2020.

rmiregistry 2020&
jstatd -J-Djava.security.policy=all.policy -p 2020

This example demonstrates starting jstatd with an external RMI registry on port 2020, bound to name AlternateJstatdServerName.

rmiregistry 2020&
jstatd -J-Djava.security.policy=all.policy -p 2020 -n AlternateJstatdServerName

Inhibiting creation of an in-process RMI registry

This example demonstrates starting jstatd such that it will not create a RMI registry if one is not found. This example assumes an RMI registry is already running. If it is not, an appropriate error message is emitted.

jstatd -J-Djava.security.policy=all.policy -nr

Enabling RMI logging capabilities.

This example demonstrates starting jstatd with RMI logging capabilities enabled. This technique is useful as a troubleshooting aid or for monitoring server activities.

jstatd -J-Djava.security.policy=all.policy -J-Djava.rmi.server.logCalls=true