即使 java 进程正在运行，jps 也不返回任何输出
我正在尝试在 Solaris 机器上调试 java 进程的一些问题，但运行 jps 不会返回任何输出。 jstack 给出错误“权限被拒绝”。该盒子是由 3 台相同服务器组成的集群的一部分，jps 和 jstack 在另外 2 台服务器上运行良好。
我发现以下论坛帖子来自有同样问题但没有答案的人： http://forums.sun.com/thread.jspa?threadID=5422237
为了澄清运行 bps 和 grep for java 正确给出了所有 java 进程，但 jps 没有提供任何内容（用“程序”和“客户端”匿名以保护有罪者）：
program @ clientdelivery2 : ~/
-> bps auxww|grep java
program 3427 5.5 54.067742726649544 ? S Sep 25 1039:47 /usr/jdk/instances/jdk1.6.0_16/bin/amd64/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/app/client/program/tomcat/conf/logging.properties -Xmx6144m -XX:PermSize=128m -XX:MaxPermSize=512m -Djava.endorsed.dirs=/app/client/program/tomcat/endorsed -classpath :/app/client/program/tomcat/bin/bootstrap.jar -Dcatalina.base=/app/client/program/tomcat -Dcatalina.home=/app/client/program/tomcat -Djava.io.tmpdir=/app/client/program/tomcat/temp org.apache.catalina.startup.Bootstrap start
program 29915 0.1 11.915252441467896 ? S 14:55:28 3:59 /usr/jdk/instances/jdk1.6.0_16/bin/amd64/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/app/clientclone/program/tomcat/conf/logging.properties -Xmx2g -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.endorsed.dirs=/app/clientclone/program/tomcat/endorsed -classpath :/app/clientclone/program/tomcat/bin/bootstrap.jar -Dcatalina.base=/app/clientclone/program/tomcat -Dcatalina.home=/app/clientclone/program/tomcat -Djava.io.tmpdir=/app/clientclone/program/tomcat/temp org.apache.catalina.startup.Bootstrap start
program 1573 0.0 0.0 4760 1332 pts/5 S 17:05:24 0:00 grep --colour java
program @ clientdelivery2 : ~/
-> jps
program @ clientdelivery2 : ~/
->
我四处询问并从这里 http://forums.oracle.com/forums/message.jspa?messageID=5408592 我知道问题是：
12460/2: mkdir("/tmp/hsperfdata_program", 0755) Err#13 EACCES [ALL]
这意味着 jps 被拒绝访问 psperfdata 目录。
有谁遇到过这个问题并知道如何解决它？
I'm trying to debug some issues with java processes on a Solaris box, but running jps returns no output. And jstack gives the error 'Permission denied'. The box is part of a cluster of 3 identical servers, jps and jstack work fine on the 2 other servers.
I found the following forum post from someone with the same problem but no answers:
http://forums.sun.com/thread.jspa?threadID=5422237
To clarify running bps and grep for java gives all java proceses correctly, but jps gives nothing (anonymised with 'program' and 'client' to protect the guilty):
program @ clientdelivery2 : ~/
-> bps auxww|grep java
program 3427 5.5 54.067742726649544 ? S Sep 25 1039:47 /usr/jdk/instances/jdk1.6.0_16/bin/amd64/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/app/client/program/tomcat/conf/logging.properties -Xmx6144m -XX:PermSize=128m -XX:MaxPermSize=512m -Djava.endorsed.dirs=/app/client/program/tomcat/endorsed -classpath :/app/client/program/tomcat/bin/bootstrap.jar -Dcatalina.base=/app/client/program/tomcat -Dcatalina.home=/app/client/program/tomcat -Djava.io.tmpdir=/app/client/program/tomcat/temp org.apache.catalina.startup.Bootstrap start
program 29915 0.1 11.915252441467896 ? S 14:55:28 3:59 /usr/jdk/instances/jdk1.6.0_16/bin/amd64/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/app/clientclone/program/tomcat/conf/logging.properties -Xmx2g -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.endorsed.dirs=/app/clientclone/program/tomcat/endorsed -classpath :/app/clientclone/program/tomcat/bin/bootstrap.jar -Dcatalina.base=/app/clientclone/program/tomcat -Dcatalina.home=/app/clientclone/program/tomcat -Djava.io.tmpdir=/app/clientclone/program/tomcat/temp org.apache.catalina.startup.Bootstrap start
program 1573 0.0 0.0 4760 1332 pts/5 S 17:05:24 0:00 grep --colour java
program @ clientdelivery2 : ~/
-> jps
program @ clientdelivery2 : ~/
->
I asked around and from here http://forums.oracle.com/forums/message.jspa?messageID=5408592 I've got that the issue is:
12460/2: mkdir("/tmp/hsperfdata_program", 0755) Err#13 EACCES [ALL]
Meaning jps is being denied access to the psperfdata directory.
Has anyone run into this issue and know how to solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
事实证明，由于安装文件系统时出现一些问题，用户无法访问 /tmp。这会导致 hsperfdata_ 内的文件永远不会被写入，即使用户有权访问 /tmp/hsperfdata_ 文件夹本身。
Turns out the user didn't have access to /tmp because of some issue with mounting the file system. This leads to the files inside hsperfdata_ to never be written, even though the user had access to the /tmp/hsperfdata_ folder itself.
tldr：
sudo jps为我工作（出于其他答案中提到的原因）tldr:
sudo jpsworked for me (for reasons invoked in other answers)确保您尝试使用 jps（顺便说一句，还有 jstack）“检测”的程序在不设置 java.io.tmpdir 设置或将其设置为系统默认值的情况下运行。
Sun Developer Network 上存在许多错误不应对临时目录位置进行硬编码, 修复了 6938627 在 -Djava.io.tmpdir 时中断 VisualVM 监控的问题 和 使用属性 java.io.tmpdir 创建临时目录 此处相关。
故事：java Java 6 Update 22 过去使用硬编码的临时目录来放置收集的数据以供 jps 和 jstack 使用。 jps 和 jstack 程序知道去哪里查找。
然而，由于有人在 Java 6 Update 23 中提出了一个“bug”，他们“修复”了它以使用 java.io.tmpdir java 运行时设置。现在，它默认为系统特定的位置，这就是“硬编码”的位置。但是，如果您在调用 java 程序时设置了该选项，那么它将使用该选项。结果：jps 和 jstack 查找它们期望的位置，但没有找到任何东西。
因此，解决方案是确保
将 java.io.tmpdir 选项设置为系统默认值（例如，在 Mac 上：）
在调用程序时 。然后jps和jstack就会找到它。
我的同事 Glyn Normington 在他的 博客< /a>. Java 6 Update 25 中显然有一个修复。
Make sure the program you are trying to 'detect' with jps (and jstack, incidentally) runs without setting the
java.io.tmpdirsetting, or setting it to the system default.There are a number of bugs on the Sun Developer Network temp dir locations should not be hardcoded, Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir and Make temporary directory use property java.io.tmpdir which are relevant here.
The story: java Java 6 Update 22 used to use a hardcoded temporary directory for putting data gathered for use by jps and jstack. The jps and jstack programs knew where to look.
However, because someone raised a 'bug' in Java 6 Update 23 they 'fixed' it to use the java.io.tmpdir java runtime setting instead. Now, this defaults to a system-specific location, which is what the 'hardcoded' one was. But if you set the option when invoking your java program, then it will use that instead. Result: jps and jstack look where they expect it to be and don't find anything.
The solution is therefore to ensure that the java.io.tmpdir option is set to the system default (e.g., on the Mac:
)
when invoking your program. Then jps and jstack will find it.
My colleague Glyn Normington describes this on his blog. There is apparently a fix in Java 6 Update 25.
另外，请确保您的启动脚本不包含
-XX:+PerfDisableSharedMem，因为使用此选项，JVM 将不会写入任何统计信息，从而使该进程对不可见jps 和 jstat。请参阅https://support.datastax.com/hc/en-us/articles/208269876-Java-utilities-such-as-jps-or-jstat-unable-to-monitor-DSE-processes< /a> 了解详细信息。
Also, make sure that your startup script does not include
-XX:+PerfDisableSharedMembecause with this option the JVM will not write any stats, making the process invisible tojpsandjstat.See https://support.datastax.com/hc/en-us/articles/208269876-Java-utilities-such-as-jps-or-jstat-unable-to-monitor-DSE-processes for details.
尝试：
Try:
您是否以运行 Java 进程的同一用户身份运行 jps？即使您以 root 身份运行 jps，它也只会返回该用户（在本例中为 root）运行的进程。
Are you running jps as the same user that is running the Java processes? Even if you run jps as root, it will only return the processes run by that user (root, in this case).