Frage kann jstatd aufgrund eines Berechtigungsfehlers nicht starten


Ich versuche, jstatd jvm Überwachungstool auf dem Linux-Rechner laufen zu lassen

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

mit folgendem Befehl:

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

jstatd.all.policy Inhalt

grant codebase "file:${java.home}/../lib/tools.jar" {

   permission java.security.AllPermission;

};

Leider bekomme ich folgende Ausgabe:

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)

Aus irgendeinem Grund läuft jstatd erfolgreich auf Windows mit demselben Befehl und derselben Richtliniendatei.

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)

50
2018-03-30 08:58


Ursprung


Antworten:


Das hat bei mir funktioniert:

  1. Stellen Sie sicher, dass die Datei tools.jar vorhanden ist und der Benutzer, der den Befehl jstatd ausführt, über Leseberechtigungen verfügt.

  2. Stellen Sie sicher, dass die URL in der jstatd.all.policy das zeigt auf die tools.jar ist korrekt und deklariert das Protokoll (Datei in diesem Fall). Zum Beispiel, abhängig davon, wo java.home variable Punkte zu, müssen Sie möglicherweise entfernen ../ Teil im Pfad genau so (ich musste):

    grant codebase "file:${java.home}/lib/tools.jar" {
       permission java.security.AllPermission;
    };
    
  3. Ab Java 1.4 muss die Richtliniendatei sein codiert in UTF-8 ohne BOM. Die EOL (CRLF vs LF) sollte nicht wirklich wichtig sein. Weitere Informationen finden Sie im Dokument "Standardrichtlinienimplementierung und Richtliniendateisyntax" von Oracle unter "Änderungen" (Link nicht angegeben, da ich nicht genügend Reputationspunkte für mehr als 2 Links habe, aber ich bin mir sicher, dass Sie Ich werde in der Lage sein, dieses Dokument zu finden).

  4. Verwenden Sie einen absoluten Pfad zur Richtliniendatei, wenn Sie den Befehl jstatd ausführen, z.

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

    EDIT: Die -J Dieser Parameter wird in Java 1.8 möglicherweise nicht mehr benötigt oder unterstützt. Daher lautet dieser Befehl:

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

    (Danke @lisak für das Aufzeigen)

  5. Schließlich, wenn Sie diesen Punkt überschreiten, können Sie andere Probleme finden (ich tat) und diese Beiträge wiesen mich in die richtige Richtung: Verwenden von VisualVM zum Überwachen einer Remote-JBoss-Instanz und Remote-Profiling von JBoss mit VisualVM. Grundsätzlich müssen Sie möglicherweise den Parameter -p verwenden, um einen anderen Port zu verwenden, wenn 1099 bereits verwendet wird, und einige Java-Optionen in JBoss hinzuzufügen run.conf über JAVA_OPTS (vorausgesetzt, Sie überwachen die JBoss-Instanz). Alles wird in den bereitgestellten Links ausführlicher erläutert.

BEARBEITEN: - spitzes totes Glied Verwenden von VisualVM zum Überwachen einer Remote-JBoss-Instanz auf eine andere Seite mit dem gleichen Inhalt.


52
2018-02-18 05:41



Habe gerade folgendes Skript zum Ausführen gefunden jstatd. Ich schaffte es zu rennen jstatd mit diesem Skript 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} &

60
2018-03-02 15:28



Ein Einleiner mit Prozesssubstitution (obwohl Bashismus):

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

Verpackt:

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

Ab jdk1.8.0_92, das Java-Launcher-Optionspräfix -J ist immer noch erforderlich.

Hinweis:

Das ursprüngliche Problem ist eher auf die Tilde zurückzuführen ~, im ~/jstatd.all.policy, wird nicht erweitert daher nicht von Java verstanden, mittlerweile entweder absoluter Pfad oder Verwendung ${HOME} sollte stattdessen funktionieren.


16
2018-05-26 14:02



Ich habe das gleiche Problem und das, was Sie tun sollten:

  1. Stelle sicher das javac ist in Ihrem $ PATH
  2. Geben Sie bei der Ausführung von jstatd den vollständigen (absoluten) Pfad zur Richtliniendatei an
    jstatd -J-Djava.security.policy=/path/to/jstatd.all.policy

Es hat mir geholfen.


2
2018-05-31 15:07



Spezifizierst du deinen Weg falsch (ich war)?

Versuchen Sie, die Richtlinie in /tmp/jstatd.all.policy zu setzen und dann auszuführen:

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

2
2018-05-31 16:30



Ich habe eine neue Richtlinie mit folgendem Inhalt erstellt:

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

und starten Sie dann jstatd mit dieser Richtlinie mit folgendem Befehl:

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


1
2018-04-07 17:06



Nur ein zusätzlicher Punkt über vorherige Antworten, die mich etwas Zeit gekostet haben, um herauszufinden.
Als ich den relativen Pfad in der Richtliniendatei verwendet habe ${java.home}/lib/tools.jar es zeigte tatsächlich auf jstatd JAVA_HOME/jre/ Verzeichnis und seit ich jdk installiert hatte musste ich verwenden ${java.home}/../lib/tools.jar anstatt an den richtigen Ort zu kommen.

BEARBEITEN Ich habe jstatd aus einem Docker-Container ausgeführt, auf dem Ubuntu mit jdk 8 läuft (JAVA_HOME wurde korrekt eingestellt).


1
2018-04-24 13:06



Zusätzlich zu LightDyes Antwort können Sie die erforderlichen Ports in Ihrem netfilter mit diesem Befehl öffnen:

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

0
2017-12-02 14:45



@michael Nesterenkos Antwort ist in Ordnung.

Aber wenn Sie manchmal den Server nicht verbinden können, selbst wenn Sie die JStatd haben, können Sie versuchen, den 'rmi.server.hostname' zuzuweisen.

#!/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.x.x &

Der Hostname muss als öffentliche IP-Adresse zugewiesen werden, wenn Sie eine Verbindung über das öffentliche Netzwerk herstellen möchten.


0
2017-09-08 09:38



Oder du kannst es benutzen ejstatd Anstatt von jstatd Das löst dieses Problem automatisch: Führen Sie es einfach mit mvn exec:java innerhalb des ejstatd-Ordners.

Disclaimer: Ich bin der Autor dieses Open-Source-Tools.


0
2017-11-02 15:12