即使 java 进程正在运行，jps 也不返回任何输出
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3805376/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
jps returns no output even when java processes are running
提问by Sindri Traustason
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.
我正在尝试在 Solaris 机器上调试 java 进程的一些问题，但运行 jps 不返回任何输出。jstack 给出错误“权限被拒绝”。该盒子是由 3 个相同服务器组成的集群的一部分，jps 和 jstack 在其他 2 个服务器上运行良好。
I found the following forum post from someone with the same problem but no answers: http://forums.sun.com/thread.jspa?threadID=5422237
我发现以下论坛帖子来自有同样问题但没有答案的人：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):
澄清运行 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 : ~/
->
I asked around and from here http://forums.oracle.com/forums/message.jspa?messageID=5408592I've got that the issue is:
我从这里四处询问http://forums.oracle.com/forums/message.jspa?messageID=5408592我知道问题是：
12460/2: mkdir("/tmp/hsperfdata_program", 0755) Err#13 EACCES [ALL]
Meaning jps is being denied access to the psperfdata directory.
这意味着 jps 被拒绝访问 psperfdata 目录。
Has anyone run into this issue and know how to solve it?
有没有人遇到过这个问题并知道如何解决？
采纳答案by Sindri Traustason
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.
事实证明，由于挂载文件系统的某些问题，用户无权访问 /tmp。这导致 hsperfdata_ 中的文件永远不会被写入，即使用户有权访问 /tmp/hsperfdata_ 文件夹本身。
回答by kschneid
Try:
尝试：
jps -J-Djava.io.tmpdir=/app/client/program/tomcat/temp
回答by Steve Powell
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.
确保您尝试使用 jps（和 jstack，顺便说一句）“检测”的程序在不设置java.io.tmpdir设置或将其设置为系统默认值的情况下运行。
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.tmpdirand Make temporary directory use property java.io.tmpdirwhich are relevant here.
Sun Developer Network临时目录位置上有许多错误不应被硬编码，修复 6938627 在 -Djava.io.tmpdir和使临时目录使用与此处相关的属性 java.io.tmpdir时破坏了 visualvm 监控。
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.
故事：java Java 6 Update 22 曾经使用硬编码的临时目录来放置收集的数据以供 jps 和 jstack 使用。jps 和 jstack 程序知道去哪里找。
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.
然而，因为有人在 Java 6 Update 23 中提出了一个“错误”，他们“修复”了它以使用 java.io.tmpdir java 运行时设置。现在，这默认为特定于系统的位置，这就是“硬编码”位置。但是，如果您在调用 java 程序时设置了该选项，那么它将改为使用该选项。结果： jps 和 jstack 查看他们期望的位置，但没有找到任何东西。
The solution is therefore to ensure that the java.io.tmpdir option is set to the system default (e.g., on the Mac:
因此，解决方案是确保将 java.io.tmpdir 选项设置为系统默认值（例如，在 Mac 上：
> java -Djava.io.tmpdir=$TMPDIR javamain
)
)
when invoking your program. Then jps and jstack will find it.
在调用你的程序时。然后 jps 和 jstack 会找到它。
My colleague Glyn Normington describes this on his blog. There is apparently a fix in Java 6 Update 25.
我的同事 Glyn Normington 在他的博客上描述了这一点。Java 6 Update 25 中显然有一个修复程序。
回答by user697547
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).
您是否以运行 Java 进程的同一用户身份运行 jps？即使您以 root 身份运行 jps，它也只会返回由该用户（在本例中为 root）运行的进程。
回答by Thomas
tldr: sudo jpsworked for me (for reasons invoked in other answers)
tldr：sudo jps为我工作（出于其他答案中提到的原因）
回答by Bombe
Also, make sure that your startup script does notinclude -XX:+PerfDisableSharedMembecause with this option the JVM will not write any stats, making the process invisible to jpsand jstat.
此外，请确保您的启动脚本并没有包括-XX:+PerfDisableSharedMem因使用此选项JVM不会写任何统计数据，制作过程不可见的jps和jstat。
See https://support.datastax.com/hc/en-us/articles/208269876-Java-utilities-such-as-jps-or-jstat-unable-to-monitor-DSE-processesfor details.
