java命令创建奇怪的PID日志文件

时间:2015-03-26 20:41:56

标签: java

我一直在使用默认安装的java版本的Amazon Linux EC2,如下所示:

java version "1.7.0_75"
OpenJDK Runtime Environment (amzn-2.5.4.0.53.amzn1-x86_64 u75-b13)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)

每当运行java独立程序(即Hello World)时,如下所示

java HelloWorld

它会自动创建一个进程ID文件,例如1234,内容如下。当我指定另一个Java_home时,使用另一个java版本,例如oracle java jdk1.7.0_71

Home/ec2-user/jdk1.7.0_71.bin/java HelloWorld

未创建文件。

如果我运行默认java但是没有创建另一个用户(root)文件。

任何想法?

sun.rt.createVmBeginTime
sun.rt.createVmEndTime
sun.rt.vmInitDoneTime
java.threads.started
java.threads.live
java.threads.livePeak
java.threads.daemon
sun.rt.safepointSyncTime
sun.rt.safepoints
sun.rt.safepointTime
sun.rt.applicationTime
sun.rt.jvmVersion
sun.rt.threadInterruptSignaled
sun.rt.interruptedBeforeIO
sun.rt.interruptedDuringIO
sun.rt.jvmCapabilities
java.cls.loadedClasses
java.cls.unloadedClasses
java.cls.sharedLoadedClasses
java.cls.sharedUnloadedClasses
sun.cls.loadedBytes
sun.cls.unloadedBytes
sun.cls.sharedLoadedBytes
sun.cls.sharedUnloadedBytes
sun.cls.methodBytes
sun.cls.time
sun.cls.classInitTime
sun.cls.classInitTime.self
sun.cls.classVerifyTime
sun.cls.classVerifyTime.self
sun.cls.classLinkedTime
sun.cls.classLinkedTime.self
sun.cls.initializedClasses
sun.cls.linkedClasses
sun.cls.verifiedClasses
sun.cls.parseClassTime
sun.cls.parseClassTime.self
sun.cls.lookupSysClassTime
sun.cls.sharedClassLoadTime
sun.cls.sysClassLoadTime
sun.cls.appClassLoadTime
sun.cls.appClassLoadTime.self
sun.cls.appClassLoadCount
sun.cls.defineAppClasses
sun.cls.defineAppClassTime
sun.cls.defineAppClassTime.self
sun.cls.appClassBytes
sun.cls.sysClassBytes
sun.cls.systemLoaderLockContentionRate
sun.cls.nonSystemLoaderLockContentionRate
sun.cls.jvmFindLoadedClassNoLockCalls
sun.cls.jvmDefineClassNoLockCalls
sun.cls.jniDefineClassNoLockCalls
sun.cls.unsafeDefineClassCalls
sun.cls.isUnsyncloadClassSet
sun.cls.loadInstanceClassFailRate
sun.gc.cause
No GC
sun.gc.lastCause
No GC
sun.gc.generation.0.name
sun.gc.generation.0.spaces
sun.gc.generation.0.minCapacity
sun.gc.generation.0.maxCapacity
sun.gc.generation.0.capacity
sun.gc.generation.0.space.0.name
eden
sun.gc.generation.0.space.0.maxCapacity
sun.gc.generation.0.space.0.capacity
sun.gc.generation.0.space.0.used
sun.gc.generation.0.space.0.initCapacity
sun.gc.generation.0.space.1.name
sun.gc.generation.0.space.1.maxCapacity

编辑:别名显示如下,但声明-f不显示任何内容。

$alias

alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias vi='vim'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

$declare -f

2 个答案:

答案 0 :(得分:2)

对我来说,答案结果是/ tmp / hsperfdata_user目录的权限未设置为x。我运行chmod +x /tmp/hsperfdata_user,其中user是受影响帐户的用户名,以便修复它。

应该注意的是,由于hsperfdata_user目录位于/ tmp中,这意味着重启也应该解决问题,具体取决于导致权限首先被更改的原因。

答案 1 :(得分:0)

我添加了" x"对dir / tmp / hsperfdata_user的权限并且它有效,奇怪的pid日志文件不再存在。