не может запустить jstatd из-за ошибки разрешения - PullRequest
52 голосов
/ 30 марта 2012

Я пытаюсь запустить инструмент мониторинга jstatd jvm на машине linux

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

с помощью следующей команды:

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

jstatd.all.policy content

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

   permission java.security.AllPermission;

};

К сожалению, я получаю следующий вывод:

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)

По какой-то причине jstatd успешно работает в Windows с тем же файлом команды и политики.

Java-версия Linux:

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)

Java-версия Windows:

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)

Ответы [ 10 ]

63 голосов
/ 02 марта 2013

Только что нашел следующий скрипт для запуска jstatd.Мне удалось запустить jstatd с этим сценарием 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} &
57 голосов
/ 18 февраля 2013

Это то, что у меня сработало:

  1. Убедитесь, что файл tools.jar существует и у пользователя, запускающего команду jstatd, есть права на его чтение.

  2. Убедитесь, что URL-адрес в jstatd.all.policy, который указывает на tools.jar, является правильным и объявляет протокол (в данном случае файл).Например, в зависимости от того, куда указывает переменная java.home, вам может понадобиться удалить часть ../ в пути, как показано ниже (мне пришлось):

    grant codebase "file:${java.home}/lib/tools.jar" {
       permission java.security.AllPermission;
    };
    
  3. Начиная с Java 1.4, файл политики должен быть закодирован в UTF-8 без спецификации .EOL (CRLF против LF) не должен иметь большого значения.Пожалуйста, смотрите документ «Реализация политики по умолчанию и синтаксис файла политики» от Oracle в разделе «Изменения» для получения дополнительной информации (ссылка не указана, потому что у меня недостаточно очков репутации, чтобы опубликовать более 2 ссылок, но я уверен, что вы 'я смогу найти этот документ).

  4. Используйте абсолютный путь к файлу политики при запуске команды jstatd, например,

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

    РЕДАКТИРОВАТЬ: -J параметр больше не требуется или не поддерживается в Java 1.8, поэтому вместо этой команды:

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

    (спасибо @lisak за указание на это)

  5. Наконецпосле прохождения этого пункта вы можете столкнуться с другими проблемами (я это сделал), и эти сообщения указали мне правильное направление: Использование VisualVM для наблюдения за удаленным экземпляром JBoss и Удаленное профилирование JBoss с использованием VisualVM .В основном вам может потребоваться использовать параметр -p, чтобы использовать другой порт, если 1099 уже используется, и добавить некоторые параметры java в JBoss run.conf через JAVA_OPTS (при условии, что вы отслеживаете экземпляр JBoss).Все объяснено более подробно в предоставленных ссылках.

РЕДАКТИРОВАТЬ: - Указанная мертвая ссылка Использование VisualVM для мониторинга удаленного экземпляра JBoss на другой странице с тем же содержимым.

17 голосов
/ 26 мая 2016

Один вкладыш, использующий процесс подстановки (хотя бышизм):

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;};')

Начиная с jdk1.8.0_92, префикс опции java launcher -J по-прежнему необходим.

Примечание:

Первоначальная проблема более вероятна из-за тильды~, в ~/jstatd.all.policy, не раскрывается, поэтому не понимается Java, в то время как либо абсолютный путь, либо использование ${HOME} должны работать.

2 голосов
/ 24 апреля 2017

Просто еще один момент о предыдущих ответах, который стоил мне немного времени, чтобы разобраться.
Когда я использовал относительный путь в файле политики ${java.home}/lib/tools.jar, он фактически указывал jstatd на каталог JAVA_HOME/jre/, и, поскольку у меня был установлен jdk, мне пришлось вместо этого использовать ${java.home}/../lib/tools.jar, чтобы добраться до нужного места.

РЕДАКТИРОВАТЬ Я запускал jstatd из контейнера-докера под управлением Ubuntu с JDK 8 (JAVA_HOME был установлен правильно).

2 голосов
/ 31 мая 2012

Вы указали неверный путь (я был)?

Попробуйте поместить политику в /tmp/jstatd.all.policy и затем запустить:

jstatd -J-Djava.security.policy=/tmp/jstatd.all.policy
2 голосов
/ 31 мая 2012

У меня та же проблема, и что вы должны сделать:

  1. Убедитесь, что javac находится в вашем $ PATH
  2. Укажите полный (абсолютный) путь к файлу политики при запуске jstatd
    jstatd -J-Djava.security.policy=/path/to/jstatd.all.policy

Это помогло мне.

1 голос
/ 07 апреля 2017

Я создал новую политику со следующим содержанием:

предоставить кодовую базу "file: /usr/java/latest/lib/tools.jar" {разрешение java.security.AllPermission; };

и затем запустите jstatd с этой политикой с помощью следующей команды:

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

0 голосов
/ 02 ноября 2016

Или вы можете использовать ejstatd вместо jstatd, который автоматически решает эту проблему: просто запустите его, используя mvn exec:java внутри папки ejstatd.

Отказ от ответственности: я являюсь авторомэто инструмент с открытым исходным кодом.

0 голосов
/ 08 сентября 2016

@ с Майклом Нестеренко все в порядке.

Но если иногда вы не можете подключиться к серверу, даже если у вас есть Jstatd, вы можете попытаться присвоить '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.x.x &

имя хоста должно быть назначено как публичный ip, если вы хотите подключиться через публичную сеть.

0 голосов
/ 02 декабря 2014

в дополнение к ответу LightDye вы можете открыть необходимые порты в сетевом фильтре с помощью этой команды:

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
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...