前端npm install报错too many levels of symbolic links解决办法

1. 在Linux环境通过Jenkins构建前端项目，只要执行npm install安装模块以后，就会报错：

node_modules/webpack/node_modules/@webassemblyjs/helper-module-context/node_modules/@webassemblyjs/ast/node_modules/@webassemblyjs/wast-parser/node_modules/@webassemblyjs/helper-code-frame/node_modules/@webassemblyjs/wast-printer/node_modules/@webassemblyjs/ast/node_modules/@webassemblyjs/wast-parser/node_modules/@webassemblyjs/helper-code-frame/node_modules/@webassemblyjs/wast-printer/node_modules/@webassemblyjs/ast/node_modules/@webassemblyjs/wast-parser/node_modules/@webassemblyjs/helper-code-frame/node_modules/@webassemblyjs/wast-printer/node_modules/@webassemblyjs/wast-parser/node_modules/@webassemblyjs/helper-code-frame/node_modules/@webassemblyjs/wast-printer/node_modules/@webassemblyjs/wast-parser/node_modules/@webassemblyjs/helper-code-frame/node_modules/@webassemblyjs/wast-printer/node_modules/@webassemblyjs/wast-parser – too many levels of symbolic links

1. 造成影响：

这个报错会导致服务器CPU持续飙高，直到Jenkins内存溢出以后，才会正常。

分析原因主要是npm install 安装的时候模块会创建软连接，然后模块之间相互引用，而这个软连接又是使用的相对路径，导致某些文件夹深度是死循环，从而会耗尽Jenkins的堆内存。

最近又被这个问题困扰，一开始也只找到npm unlink之类的处理方法，此方法不太现实。

最后终于在谷歌找到一篇文章说了这个问题的解决方法，分享给遇到此问题的童鞋。

1. 原因：

npm默认会使用symbolic links来安装组件，也即我们在linux系统里经常用的软链接（ln -s）或硬链接(ln)，但是有些文件系统不支持文件链接，比如Windows（或者说出于安全原因禁用了），有时候linux系统运行在有windows分区的硬盘上也不支持链接，比如virtualbox在windows主机上默认禁止在共享文件夹里使用symbolic links。

1. 解决办法：

在npm install的时候加上一个参数，就是–no-bin-links，也即npm install --no-bin-links。（The --no-bin-links argument will prevent npm from creating symlinks for any binaries the package might contain.）或者全局设置npm config set bin-links false，这样其他npm命令后面就不需要添加–no-bin-links。

在cnpm install的时候加上一个参数，就是–no-bin-links，也即cnpm install --no-bin-links。（The --no-bin-links argument will prevent cnpm from creating symlinks for any binaries the package might contain.）或者全局设置cnpm config set bin-links false，这样其他cnpm命令后面就不需要添加–no-bin-links。

其他解决办法：

jenkins 官网：https://issues.jenkins.io/browse/JENKINS-40421
too many levels of symbolic links/Archiving artifact stuck
Export
Details
Type: Bug
Status:OPEN (View Workflow)
Priority: Major
Resolution:Unresolved
Component/s:
core
Labels:
archiving artifacts core
Environment:core 1.642.3
Similar Issues:
Description
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
Issue Links
is related to
Bug - A problem which impairs or prevents the functions of the product. JENKINS-36559 File pattern (e.g. archive) field validation can run forever Critical - Crashes, loss of data, severe memory leak. OPEN
Bug - A problem which impairs or prevents the functions of the product. JENKINS-40999 Recursive symlink causes high resource utilization, termination of slave process in ArchiveArtifact and Publish JUnit results steps. Minor - Minor loss of function, or other problem where easy workaround is present. OPEN
Bug - A problem which impairs or prevents the functions of the product. JENKINS-41135 java.lang.OutOfMemoryError: Java heap space with 100% CPU usage Critical - Crashes, loss of data, severe memory leak. RESOLVED
Activity
All
Comments
History
Activity
Ascending order - Click to sort in descending order
Permalink
oleg_nenashev
Oleg Nenashev added a comment - 2016-12-22 07:45
“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.

Permalink
danielbeck
Daniel Beck added a comment - 2016-12-23 19:26
Weirdly enough the archiving code is supposed to detect cycles and abort. I think there are other issues related to this.

Permalink
lmcazra
Audrey Azra added a comment - 2017-01-19 13:44
https://github.com/jenkinsci/jenkins/blob/08def67a18eee51de9f3f99bc2a792fee1c160e0/core/src/main/java/hudson/tasks/ArtifactArchiver.java#L251
perhaps tuning system property value hudson.FilePath.VALIDATE_ANT_FILE_MASK_BOUND?
Any recommendations or other suggestions Daniel?

Permalink
danielbeck
Daniel Beck added a comment - 2017-01-19 14:02
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.

Permalink
solarus
David Spångberg added a comment - 2017-02-12 17:14 - edited
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. withfs.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.

Permalink
krlf
Kirill Fedoseev added a comment - 2017-05-04 09:24
Have the same issue. It breaks our slaves.

Permalink
evildeece
Alastair D’Silva added a comment - 2017-05-05 01:55
I worked around the issue by not using ‘**’ to glob directories that contained symlinks to itself, but instead specified the exact files I required.

Permalink
vasba
Vasile Baluta added a comment - 2018-12-12 20:29
Hi!

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.

People
Assignee:
Unassigned
Unassigned
Reporter:
lmcazra
Audrey Azra
Votes: 3 Vote for this issue
Watchers: 9 Start watching this issue
Dates
Created: 2016-12-13 21:00
Updated: 2018-12-12 20:29