Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63118

Maven Projects don't delete temp 'resource-xxx' directories from /tmp

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core, (2)
      maven-plugin, remoting
    • Jenkins ver. 2.190.2 on Ubuntu Linux 64-bit
      os.version = 4.4.0-177-generic
      openjdk-8 (1.8.0_232)

      We've noticed that the /tmp directory on our slaves is filling up with directories with names beginning with "resource-" (ex. "resource-504258138138001911").

      I was able to narrow down how to reproduce the issue.  Most of our jobs are "Freestyle" projects, but one is a "Maven Project"; and whenever that job runs, it creates a /tmp/resources-xxx temp directory but never deletes it.  The Freestyle projects that run the exact same "mvn clean install" command using the Execute shell plugin don't experience this issue.

      If you want to reproduce it, create a Maven Project, clone a git repo that has a maven project that has some JUnit tests.  Run "ls -al /tmp" before and after executing the "clean install" maven goal.  You will see 2 new /tmp/resource directories after running the Maven goal (which should also run some tests).

       

      My guess as to the problem is someone is probably calling Files.createTempDirectory("resource-") without calling File.deleteOnExit() afterwards.

          [JENKINS-63118] Maven Projects don't delete temp 'resource-xxx' directories from /tmp

          My guess as to the problem is someone is probably calling Files.createTempDirectory("resource-") without calling File.deleteOnExit() afterwards.

           

          Yes, here, in hudson.remoting.Util.makeResource(...):

          https://github.com/jenkinsci/remoting/blob/911aaf629c9fcbc80dd5e2c5de8bdd37a6103570/src/main/java/hudson/remoting/Util.java#L66

          It seems to be a regression introduced 3 years ago in this PR:

          https://github.com/jenkinsci/remoting/pull/109

          ...in this chunk:

          https://github.com/jenkinsci/remoting/commit/49c67eef8616c7bc3588263d4ecc2dbcb51d5bb8#diff-b745b330d4eab6db1c614f5796177cf8R57

          In this code, deleteDirectoryOnExit(File) is a utility function to recursively call deleteOnExit() on a hierarchy of directories and files.  Before this change, it was called on the temporary "resource-xxxx" directory itself, but with this change it got called only on the temporary file which is getting created inside the temporary directory, and no more on the temporary directory itself.

          So this is not specific to the Maven plugin, it's rather a Remoting bug.

          Actually, I see it on my agents without using the Maven plugin, but via the BouncyCastle plugin, because of this chain of calls:

          (in my case, InstallBouncyCastleJCAProvider.on(...) is called by some internal plugin, but it doesn't really matter, it seems the ssh-agent-plugin does it to)

          Thomas de Grenier de Latour added a comment - My guess as to the problem is someone is probably calling Files.createTempDirectory("resource-") without calling File.deleteOnExit() afterwards.   Yes, here, in hudson.remoting.Util.makeResource(...) : https://github.com/jenkinsci/remoting/blob/911aaf629c9fcbc80dd5e2c5de8bdd37a6103570/src/main/java/hudson/remoting/Util.java#L66 It seems to be a regression introduced 3 years ago in this PR: https://github.com/jenkinsci/remoting/pull/109 ...in this chunk: https://github.com/jenkinsci/remoting/commit/49c67eef8616c7bc3588263d4ecc2dbcb51d5bb8#diff-b745b330d4eab6db1c614f5796177cf8R57 In this code, deleteDirectoryOnExit(File) is a utility function to recursively call deleteOnExit() on a hierarchy of directories and files.  Before this change, it was called on the temporary " resource-xxxx " directory itself, but with this change it got called only on the temporary file which is getting created inside the temporary directory, and no more on the temporary directory itself. So this is not specific to the Maven plugin, it's rather a Remoting bug. Actually, I see it on my agents without using the Maven plugin, but via the BouncyCastle plugin, because of this chain of calls: InstallBouncyCastleJCAProvider.on(Channel) Channel.preloadJar(...) PreloadJarTask.call() RemoteClassLoader.prefetch(...) Util.makeResource(...) (in my case,  InstallBouncyCastleJCAProvider.on(...) is called by some internal plugin, but it doesn't really matter, it seems the ssh-agent-plugin does it to )

          Here is PR to fix that: https://github.com/jenkinsci/remoting/pull/393

          Not really tested yet.

          Thomas de Grenier de Latour added a comment - Here is PR to fix that: https://github.com/jenkinsci/remoting/pull/393 Not really tested yet.

          Jeff Thompson added a comment -

          This may be fixed by the referenced PR, once it is released in Remoting and integrated into Jenkins. I haven't been able to verify the problem or the fix, but the fix shouldn't break anything and is likely to make improvements in areas like this.

          After integration we should go ahead and close this issue, assuming it to be fixed. If that turns out to not be the case, it can be re-opened.

          Jeff Thompson added a comment - This may be fixed by the referenced PR, once it is released in Remoting and integrated into Jenkins. I haven't been able to verify the problem or the fix, but the fix shouldn't break anything and is likely to make improvements in areas like this. After integration we should go ahead and close this issue, assuming it to be fixed. If that turns out to not be the case, it can be re-opened.

            Unassigned Unassigned
            cpjust Chris Just
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: