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

Recursive symlink causes high resource utilization, termination of slave process in ArchiveArtifact and Publish JUnit results steps.


    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core, junit-plugin
    • None
    • Jenkins v2.35 in docker container, SSH build slaves, JUnit plugin 1.19

      Per JENKINS-7780 I am filing a new issue as I was able to reproduce the same issue on a current version of Jenkins.

      I am seeing the same issue affecting my build slaves in situations where I have a symlink that points upwards to a directory higher than my jenkins workspace. Each build slave has multiple projects being built on it and each project has 4 of these symlinks. Each project consist of many files (multiple copies of the linux kernel, multiple root filesystem images, our application code and our build artifacts). Based on strace-ing the JVM it appears that jenkins is recursively stat'ing files through these symlinks. Because the symlinks points to a directory that contains all project directories it results in a HUGE fanout and eventually the slave disconnects when the JVM is killed, causing all builds on the slave node to fail.

      By process of elimination I was able to determine that both the ArtifactArchiver and the JUnit Publisher steps cause this problem. Both use org.apache.tools.ant.FileSet to handle the pattern match/file collection. While this class does recursive loop detection caused by symlinks it doesn't do it fast enough to prevent the huge fanout that brings down the build nodes.

      Even more interesting - because the project config page seems to "test" the patterns entered into the UI for ArchiveArtifact and Publish JUnit against the workspace, just opening the config page would cause the issue to occur and the slave to eventually disconnect.

      I would be happy if there was a way to disable the following of symlinks. I understand that the org.apache.tools.ant.types.AbstractFileSet has a followSymlinks member that defaults to true. If I could set this to false via the Jenkins UI then corner cases like our horrendous repo would be covered without breaking it for those who rely on the symlink-traversing behavior.

            Unassigned Unassigned
            mikenicholson Mike Nicholson
            0 Vote for this issue
            5 Start watching this issue