jstatd
Virtual Machine jstat Daemon
Synopsis
jstatd [
options ]
add an example, a script, a trick and tips
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
source
jstatd -J-Djava.security.policy=jstatd-all.policy -p 1099
source
sudo jstatd -J-Djava.security.policy=/usr/lib/jvm/default-java/bin/jstatd.all.policy
-J-Djava.rmi.server.logCalls=true
source
/usr/java/jdk1.6.0_34/bin/jstatd
-J-Djava.security.policy=../conf/tools.policy &
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 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.
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.
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.
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(TM) 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 @
http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html.
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.
see also
*
java - the Java
Application Launcher
*
jps - the Java Process Status Application
*
jstat - the Java Virtual Machine Statistics
Monitoring Tool
*
rmiregistry - the Java Remote Object Registry