Telebh Telebh - 6 months ago 16
Java Question

java command creates weird PID log file

I have been using Amazon Linux EC2 with default installed java version as below:

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)


Whenever run a java standalone program (i.e. Hello World) as follows

java HelloWorld


it automatically creates a process ID file for example 1234 with contents as follows. When I specify another Java_home, with another java version, for example oracle java jdk1.7.0_71

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


the file is not created.

If I run default java but as another user (root) file not created.

ANY Idea?

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


Edit: alias shows as below, but declare -f shows nothing.

$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

Answer

For me the answer turned out to be that the permission for the /tmp/hsperfdata_user directory was not set to x. I ran chmod +x /tmp/hsperfdata_user, where user is the username of the affected account, to fix it.

It should be noted that since the hsperfdata_user directories reside in /tmp that means a reboot should also fix the issue, depending on what it is that caused the permissions to be changed in the first place.

Comments