Duplicate and Inspection Runners choke on symbolic link loops

I configured a Teamcity Duplication runner build - the runner tries to build a command line, and as part of that it (apparently) runs through the JDK_HOME directory looking for subdirectories. In the JDK as installed there’s a symbolic link “sdk -> ./”, and this seems to cause an infinite loop in a Teamcity utility.

 

Here’s stack trace, with the middle lines elided:

 

Failed to create IDEA configuration files:

[06:49:41]: java.io.IOException: Too many levels of symbolic links


java.io.IOException: Too many levels of symbolic links


at java.io.UnixFileSystem.canonicalize0(Native Method)


at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:157)
at java.io.File.getCanonicalPath(File.java:559)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineGenerateUtil.collectFiles(IdeaCommandLineGenerateUtil.java:216)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineGenerateUtil.collectFiles(IdeaCommandLineGenerateUtil.java:217)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineGenerateUtil.collectFiles(IdeaCommandLineGenerateUtil.java:217)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineGenerateUtil.processRelativeToPatterns(IdeaCommandLineGenerateUtil.java:194)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineGenerateUtil.generateJdkTable(IdeaCommandLineGenerateUtil.java:146)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineRunner.generateGlobalSettings(IdeaCommandLineRunner.java:115)


at jetbrains.buildServer.ideaCommandLine.runner.IdeaCommandLineRunner.getVMProperties(IdeaCommandLineRunner.java:81)


at jetbrains.buildServer.agent.runner.JavaProgramRunner.buildCommandLine(JavaProgramRunner.java:65)


at jetbrains.buildServer.agent.runner.GenericProgramRunner.run(GenericProgramRunner.java:103)


at jetbrains.buildServer.agent.impl.runner.adapt.BuildProcessImpl$2.run(BuildProcessImpl.java:55)


at java.lang.Thread.run(Thread.java:619)

 

In our environment the JDK is being installed on the server by a central group. The (unsatisfactory) fix was to create a deep copy of the JDK directory, delete the sdk symbolic link, and point the runner at the copy. It’s unsatisfactory because we now have duplication of the JDK, which sounds like a bad idea. An alternative might be to delete the symbolic link from the original JDK installation, but that means messing with a piece of managed software, which also sounds like a bad idea (and it wouldn’t survive a reinstall).

This looks like a bug - has anyone else had this experience?

Please sign in to leave a comment.