Status: Open (View Workflow)
When we have the symbolic links in src code like,
dir1 -> .
dir2 -> ../../../..
Symptoms observed during this problematic phase:
- The “Archiving artifact” step under Post- build phase get stuck. We can see the never ending cycling icon…
- the slave node will report error like “too many levels of symbolic links” and ping response time would gradually degrade, eventually killing the slave.
- the build log may also have error like WARN: Caught error while checking for symbolic links
- is related to
JENKINS-36559 File pattern (e.g. archive) field validation can run forever
JENKINS-40999 Recursive symlink causes high resource utilization, termination of slave process in ArchiveArtifact and Publish JUnit results steps.
JENKINS-41135 java.lang.OutOfMemoryError: Java heap space with 100% CPU usage
Weirdly enough the archiving code is supposed to detect cycles and abort. I think there are other issues related to this.
perhaps tuning system property value hudson.FilePath.VALIDATE_ANT_FILE_MASK_BOUND?
Any recommendations or other suggestions Daniel?
In JENKINS-36559 I got the impression that that option didn't work, but it's been a while since I've looked.
No suggestions right no other than ensuring you don't have loops.
The "to many levels of symbolic links" comes from "org.apache.tools.ant.DirectoryScanner.scandir" it seems.
I tried the config.xml example from JENKINS-36559 and modified `hudson.Util.createFileSet(File, String, String)' to not follow symlinks, i.e. with `fs.setFollowSymlinks(false)'. Without the change I get slow archiving and the "too many levels of symbolic links" error log messages above. With the change the mentioned example seems to run ok. I'm testing on 1.642.4 instead of 1.642.3 though but I suppose that does not really matter.
I worked around the issue by not using '**' to glob directories that contained symlinks to itself, but instead specified the exact files I required.
Some updates related to versions from 2.89.2 and above.
If anyone needs to do a patch then the solution proposed by David Spånberg is partly complete.
setFolowSymlinks(false) needs also to be called for the instance of "org.apache.tools.ant.DirectoryScanner" created in method hasMatch in class hudson.FilePath.
"too many levels of symbolic links" comes from the operating system, it has nothing to do with Jenkins. From what I see dir2 points to the directory, which contains dir2. In such case it will cause the infinite recursion cycle in the operating system.