1

Noticed an odd behavior that started after moving from Java 7 to Java 8 (HotSpot 64-Bit Server) on Red Hat Linux. The problem happens for one particular user, whose jobs typically run in batch and who cannot log on at a signon prompt. Each time a command such as "java -jar hello.jar" is run by this user, a 32 KB binary file with a numeric filename (such as 18362 or 24339) is created in the current directory.

The first several readable phrases from one of the numeric files look like the following:

8J0sun.rt._sync_Inflations8J0sun.rt._sync_Deflations@J8sun.rt._sync_ContendedLockAttempts8J0sun.rt._sync_FutileWakeups0J(sun.rt._sync_Parks@J8sun.rt._sync_EmptyNotifications8J0sun.rt._sync_Notifications8J0sun.rt._sync_SlowEnter8J0sun.rt._sync_SlowExit8J0sun.rt._sync_SlowNotify8J0sun.rt._sync_SlowNotifyAll8J0sun.rt._sync_FailedSpins@J8sun.rt._sync_SuccessfulSpins8J0sun.rt._sync_PrivateA8J0sun.rt._sync_PrivateB@J8sun.rt._sync_MonInCirculation8J0sun.rt._sync_MonScavenged8J0sun.rt._sync_MonExtant

We now have over 6,000 32 KB files with a numeric filename in the directory from which the "java" command is launched.

This is on a production server. We don't have the same problem on a development server. However, the user in question has the ability to log onto the development server (say with putty) -- whereas the user can't do that on the production server.

I'd like to know what causes the creation of all these files and how to prevent it.

user5692647
  • 23
  • 2
  • it would be easier to answer if we'd know what does the jar file in question actually do – eis Dec 17 '15 at 21:19
  • 2
    I suspect these are crash dumps or traces. Does the user report any application failures? – user207421 Dec 17 '15 at 21:25
  • It doesn't matter which jar file is run; it generates a new numbered file in every case (for this one user). The "hello.jar" mentioned simply prints "Hello world!". Also, the jar executions run fine without failure. – user5692647 Dec 18 '15 at 12:06

1 Answers1

0

Searching on a couple of the symbols in the "readable" line seems to point to hsperfdata artifacts; see this Github hsperfdata parser project. They are very likely safe to remove after java exits.

Note: If these are hsperfdata artifacts, the numbers are process identifiers. You might have these lying around on the development system in the usual temporary directories.

(Original hypothesis that the leftover files might be class file artifacts extracted from the JAR file removed.)

scooter me fecit
  • 1,053
  • 5
  • 15
  • can you explain the concept of "temporary class files" to me? Never heard of such a thing. – eis Dec 17 '15 at 21:18
  • 1
    why would java extract the .jar file into files? That's not how java usually works. Jar files are read directly and classes are loaded into memory, not saved to disk. Saving them to disk doesn't make much sense to me, nor have I heard about it before (and I've been in java scene for some while) – eis Dec 17 '15 at 21:24
  • 1
    This is not a likely hypothesis. There is nothing in the file that looks remotely like a .class file, and Java doesn't need to extract class files into local files, but if it does it needs to put them into files named after the class. – user207421 Dec 17 '15 at 21:24
  • 1
    I would be interested to see some evidence (reference links or something) of java _ever_ behaving the way you described. – eis Dec 17 '15 at 21:25
  • Doing a quick search on one of the symbol names seems to point to these files as being _hsperdata_ artifacts. Curiously, none of the comments pointed in this direction, just jumped on a bad starting hypothesis. The upshot is that these files are likely safe to remove after `java` exits. – scooter me fecit Dec 17 '15 at 22:39
  • 1
    Expecting comments to point in any direction is fallacious. You don't have to be able to lay an egg to spot a rotten one. – user207421 Dec 17 '15 at 23:31
  • EJP: It's all fine and good to point out what something is "likely not". It's just as important to point out what something "likely is." – scooter me fecit Dec 17 '15 at 23:36
  • @ScottM: the comments here are meant to address the answer as it is in any given situation. Your initial answer was just wrong, but there is nothing wrong with deleting it and creating a new one, for example, assuming the new answer doesn't really relate to old one in any way. – eis Dec 18 '15 at 05:42
  • Assuming they are hsperfdata files, you might want to point OP to [disabling hsperfdata files](http://stackoverflow.com/questions/76327/how-can-i-prevent-java-from-creating-hsperfdata-files) instead of removing them afterwards, given that OP doesn't have the requirement to use visualvm, jconsole or similar tool to track application performance. – eis Dec 18 '15 at 05:47
  • Thanks for pointing me in the direction of hsperfdata. Further googling led me here: https://upc-bugs.lbl.gov/blcr/doc/html/FAQ.html#hsperfdata . It turns out that I needed to do a "chmod 755 /tmp/hsperfdata_[username]". Not sure how the permissions got messed up, but all is good now. – user5692647 Dec 18 '15 at 12:41
  • @eis: There's nothing preventing someone from rogering up a better answer. We all make educated guesses based on our experience working with systems; my initial guess was based on my previous experience with Java (I've seen remnant unzipped JAR artifacts before back in the mid and late '90s.) – scooter me fecit Dec 18 '15 at 17:25
  • @user5692647: Glad you were able to resolve the problem. Sorry about the initial poor guess. – scooter me fecit Dec 18 '15 at 17:26