Cannot start jstatd due to permission error

Question

I am trying to run jstatd jvm utility for monitoring on linux machine

jboss@hostAddr:/usr/java/jdk1.6.0_18/bin> uname -a Linux hostAddr 2.6.16.60-0.34-smp #1 SMP Fri Jan 16 14:59:01 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux 

with the following command:

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

Jstatd.all.policy content

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

Unfortunately, I get the following output:

 Could not create remote object access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write) java.security.AccessControlException: access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.System.setProperty(System.java:725) at sun.tools.jstatd.Jstatd.main(Jstatd.java:122) 

For some reason, jstatd runs successfully on Windows with the same batch and political file.

Linux java version:

 java version "1.6.0_18" Java(TM) SE Runtime Environment (build 1.6.0_18-b07) Java HotSpot(TM) 64-Bit Server VM (build 16.0-b13, mixed mode) 

Windows java version:

 java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) 

Answer 1

This is what worked for me:

• Verify that the tools.jar file exists and that the user running the jstatd command has permission to read it.

• Make sure the URL in jstatd.all.policy , which points to tools.jar, is correct and declares the protocol (in this case, the file). For example, depending on where the java.home variable is java.home , you may need to remove the ../ part in the path as it was (I had to):

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

• Starting with Java 1.4, the policy file must be encoded in UTF-8 without specification . EOL (CRLF vs. LF) doesn't really matter. For more information, see Oracle's “Policy Implementation Policy Syntax and Political File” section under “Changes” (link not specified because I do not have enough reputation points to post more than two links, but I'm sure you can find this document).

• Use the absolute path to the policy file when running the jstatd command, for example

   jstatd -p 12345 -J-Djava.security.policy=/absolute-path-to/jstatd.all.policy 

  EDIT: The -J may no longer be required or supported in Java 1.8, so instead of this command:

   jstatd -p 12345 -Djava.security.policy=/absolute-path-to/jstatd.all.policy 

  (thanks @lisak for pointing this out)

• Finally, once you get past this point, you may find other problems (I did), and these messages pointed me in the right direction: Using VisualVM to control a remote JBoss instance and Remote JBoss profiling using VisualVM . Basically, you might need to use the -p option to use a different port if 1099 is already in use, and add java options to JBoss run.conf via JAVA_OPTS (assuming that you are in control of the JBoss instance). Everything is explained in more detail in the links provided.

EDIT: - Indicated dead link Using VisualVM to monitor a remote JBoss instance on another page with the same content.

Answer 2

A script has just been found to run jstatd . I managed to run jstatd using this script https://gist.github.com/nicerobot/1375032

 #!/bin/sh policy=${HOME}/.jstatd.all.policy [ -r ${policy} ] || cat >${policy} <<'POLICY' grant codebase "file:${java.home}/../lib/tools.jar" { permission java.security.AllPermission; }; POLICY jstatd -J-Djava.security.policy=${policy} & 

Answer 3

One insert using a process replacement (albeit a bagism):

 jstatd -p 1099 -J-Djava.security.policy=<(echo 'grant codebase "file:${java.home}/../lib/tools.jar" {permission java.security.AllPermission;};') 

wrapped:

jstatd -p 1099 -J-Djava.security.policy=<(echo 'grant codebase "file:${java.home}/../lib/tools.jar" {permission java.security.AllPermission;};')

As with jdk1.8.0_92 , the java launcher -J option prefix is ​​required.

Note:

The original problem, most likely due to the tilde ~ , in ~/jstatd.all.policy , does not expand, therefore java is not understood, meanwhile, either the absolute path or the use of ${HOME} should work.

Answer 4

I have the same problem and what you should do:

• Make sure javac is in $ PATH
• Specify the full (absolute) path to the policy file when running jstatd
  jstatd -J-Djava.security.policy=/path/to/jstatd.all.policy

It helped me.

Answer 5

Are you pointing your way wrong (I was)?

Try entering the policy in /tmp/jstatd.all.policy and then run:

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

Answer 6

One more question about previous answers that cost me a bit of time to figure out.
When I used the relative path in the policy file ${java.home}/lib/tools.jar , it actually pointed jstatd to the JAVA_HOME/jre/ directory, and since I had jdk installed, I had to use ${java.home}/../lib/tools.jar instead to get to the right place.

EDIT I ran jstatd from a docker container that is running ubuntu with jdk 8 (JAVA_HOME was installed correctly).

Answer 7

in addition to LightDye's answer, you can open the required ports in your network file with this command:

 for port in `netstat -nlp | grep jstatd | sed -r 's/^.*\:([0-9]{4,}).*$/\1/'`; do iptables -I INPUT 1 -p tcp --dport $port -j ACCEPT -m comment --comment jstatd; done 

Answer 8

@michael nesterenko the answer is all right.

But if sometimes you can’t connect the server, even if you have Jstatd, you can try to assign 'rmi.server.hostname'

 #!/bin/sh policy=${HOME}/.jstatd.all.policy [ -r ${policy} ] || cat >${policy} <<'POLICY' grant codebase "file:${java.home}/../lib/tools.jar" { permission java.security.AllPermission; }; POLICY jstatd -J-Djava.security.policy=${policy} -J-Djava.rmi.server.hostname=192.168.xx & 

the host name must be assigned as a public ip if you want to connect through a public network.

Answer 9

Or you can use ejstatd instead of jstatd , which automatically handles this problem: just start it using mvn exec:java inside the ejstatd folder.

Disclaimer: I am the author of this open source tool.

Answer 10

I created a new policy with the following content:

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

and then run jstatd with this policy with the following command:

jstatd -J-Djava.security.policy = / usr / java / jstatd.all.policy &