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 J2SE SDK. It is not currently available on the Windows 98 and Windows ME platforms.
Tag | Description |
---|---|
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. |
Tag | Description |
---|---|
-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 by specifying this option. However, doing so will require that the unique server name be included in the monitoring clients 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. |
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, Sun recommends that the jstatd security policy be customized to meet your specific needs.
The jstatd server can only monitor JVMs for which it has the appropriate access permissions. However, jstatd does not perform any user level authentication or authorization checking. Therefore, it opens access to the instrumentation exported by the JVMs for which the jstatd server has the appropriate access permissions, allowing arbitrary users on the network to monitor JVMs that might otherwise be inaccessible. Such exposure may be unacceptable in your environment. Particular care should be exercised when running the jstatd server with credentials that allow wide exposure, such as running the server with root permissions on UNIX based systems.
The exposure introduced by the jstatd server can be eliminated by not running the server, thus requiring all monitoring activities to be performed locally. Alternatively, the security policy file can be customized to limit access to specific trusted hosts.
jstatd -J-Djava.security.policy=all.policy
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
jstatd -nr
jstatd -J-Djava.security.policy=all.policy -J-Djava.rmi.server.logCalls=true
This example uses the Bourne Shell syntax for setting environment variables, other shells or command interpreters may require different syntax.
Advertisements |