jstatd - Unix, Linux Command
NAME
jstatd - Virtual Machine jstat Daemon
SYNOPSIS
jstatd [options] 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 J2SE SDK.
It is not currently available on the Windows 98 and
Windows ME platforms.
PARAMETERS
| 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.
|
OPTIONS
The
jstatd command supports the following options:
| 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 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 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 policy file can be specified with
the -J-Djava.security.policy=file
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.
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.
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
|
This example uses the Bourne Shell syntax for setting environment
variables, other shells or command interpreters may require different
syntax.
SEE ALSO
|
