Often times users have some confusion around the New Relic Java agent creating a number of JARS in the
/temp folder of their application. Sometimes we see reports of these files being responsible for issues in an application, or the user is not able to deploy the agent due to these items being missing. Let’s address some of the common questions and concerns around the agent’s temporary JARs:
“What are all of these JAR files showing up in my
The agent creates these temporary files to do its work on JVM startup. They are named similar to the following and utilize a timestamp in naming, so they will differ slightly:
/tmp/testerdata_xyz/12345 /tmp/agent-bridge12345.jar /tmp/instrumentation12345.jar /tmp/newrelic-api12345.jar /tmp/newrelic-bootstrap12345.jar /tmp/newrelic-weaver-api12345.jar
“How can I override the path for JAR files that are auto-generated by the agent?”
The temporary folder that the agent JARS are added to by the agent on startup is controlled by the
java.io.tmpdir environment variable. You can find the current value of
java.io.tmpdir by executing the following command:
ps -ef | grep java.io.tmpdir
For example, on Tomcat you may get an output similar to:
“I am seeing multiple versions of the previously listed files being created and they do not get removed automatically. The folder is growing very large and is causing problems in my application!”
The agent removes these files on shutdown under normal circumstances. If they are not being removed correctly (and the folder is growing with numerous JARs) then this suggests that the agent or JVM is not shutting down gracefully. The best way to troubleshoot whether this is what is happening in your application is to review the agent logs at INFO level for the following startup and shutdown entries:
Sep 26, 2018 10:55:24 -0700 [9197 1] com.newrelic INFO: New Relic Agent v4.6.0 has started
Sep 26, 2018 11:38:22 -0700 [9197 1] com.newrelic.agent.Agent INFO: New Relic Agent has shutdown
As you might imagine, there should be a shutdown for every startup entry. If there is not, the agent or JVM is probably “having the rug yanked out from under it”.
“I keep seeing
java.io.File.createNewFileerrors in the logs when the agent fails to start.”
Error bootstrapping New Relic agent: java.lang.RuntimeException: java.io.IOException: No such file or directory java.lang.RuntimeException: java.io.IOException: No such file or directory at com.newrelic.bootstrap.BootstrapLoader.load(BootstrapLoader.java:128) at com.newrelic.bootstrap.BootstrapAgent.startAgent(BootstrapAgent.java:135) at com.newrelic.bootstrap.BootstrapAgent.premain(BootstrapAgent.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382) at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397) Caused by: java.io.IOException: No such file or directory at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:1006) at java.io.File.createTempFile(File.java:1981) at java.io.File.createTempFile(File.java:2032) at com.newrelic.bootstrap.EmbeddedJarFilesImpl$1.load(EmbeddedJarFilesImpl.java:36) at com.newrelic.bootstrap.EmbeddedJarFilesImpl$1.load(EmbeddedJarFilesImpl.java:26)
This error indicates the Java agent’s attempt to create the necessary temp files and not being able to find and/or write to the temp directory. You may need to confirm that the temp directory can be written to by the agent and user running the java process.
“I am trying to deploy New Relic Java on an application in a containerized environment with a read-only file system (including
/tmpdirectory). Is there a way to run New Relic without writing to the disk?”]
Unfortunately, the JARs are necessary for the agent to run, and it needs them available to it at startup. If you are unable to write the necessary JARs to the default or other location, this might not be a supported environment for the Java agent.