`npm uninstall`掛起（或非常緩慢）而沒有明顯的活動

Question

我一直發現npm uninstall要花費很長時間，並且正在嘗試進行故障排除。 我在大約25分鍾前開始卸載四個軟件包，它似乎停滯了，沒有任何進展，沒有明顯的CPU活動，也沒有明顯的磁盤活動（使用iotop ）。 我不知所措。

這是當前輸出（匿名），其日志級別為“傻”：

$ npm uninstall --save-dev -ddd gulp-autoprefixer gulp-sass gulp-sequence gulp-sourcemaps
npm info it worked if it ends with ok
npm verb cli [ '/path/to/home/bin/node-v0.12.2-linux-x64/bin/node',
npm verb cli   '/path/to/home/bin/node-v0.12.2-linux-x64/bin/npm',
npm verb cli   'uninstall',
npm verb cli   '--save-dev',
npm verb cli   '-ddd',
npm verb cli   'gulp-autoprefixer',
npm verb cli   'gulp-sass',
npm verb cli   'gulp-sequence',
npm verb cli   'gulp-sourcemaps' ]
npm info using npm@2.7.4
npm info using node@v0.12.2
npm verb unbuild node_modules/gulp-autoprefixer
npm verb unbuild node_modules/gulp-sass
npm verb unbuild node_modules/gulp-sequence
npm verb unbuild node_modules/gulp-sourcemaps
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-autoprefixer is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-autoprefixer
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-sass is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-sass
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-sequence is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-sequence
npm sill gentlyRm /path/to/home/myproject/node_modules/gulp-sourcemaps is being purged from base /path/to/home/myproject
npm verb gentlyRm don't care about contents; nuking /path/to/home/myproject/node_modules/gulp-sourcemaps
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-autoprefixer
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-sass
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-sequence
npm sill vacuum-fs purging /path/to/home/myproject/node_modules/gulp-sourcemaps

...自從我啟動它后不久，它就一直停在那里。 較早的嘗試一次刪除一個軟件包的嘗試有效，但仍然在vacuum-fs步驟停頓了一段時間（約30秒）。 我在具有8 GB內存，Node v0.12.2和npm 2.7.4的四核Intel i5上運行Ubuntu 14.04 LTS。

有誰知道問題可能在哪里或如何進一步排除故障？

（順便說一句，我不確定這是否是適用於工具問題的StackExchange網站，所以如果不是，請建議否則！）

---

編輯：我根據下面@dekkard的回答使用strace偵查； 以下是發生減速的區域的摘錄（以strace -f -t -o out.log npm uninstall -D gobble為例）：

...
18327 17:00:52 rmdir("/path/to/home/myproject/node_modules/gobble/node_modules/minimatch" <unfinished ...>
18318 17:00:52 read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
18318 17:00:52 epoll_wait(5,  <unfinished ...>
18325 17:00:55 <... rmdir resumed> )    = -1 ENOTEMPTY (Directory not empty)
18325 17:00:55 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
18325 17:00:55 rmdir("/path/to/home/myproject/node_modules/gobble/node_modules/mkdirp" <unfinished ...>
18318 17:00:55 <... epoll_wait resumed> {{EPOLLIN, {u32=8, u64=8}}}, 1024, -1) = 1
18318 17:00:55 read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
18318 17:00:55 epoll_wait(5,  <unfinished ...>
18328 17:00:58 <... rmdir resumed> )    = -1 ENOTEMPTY (Directory not empty)
18328 17:00:58 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
18318 17:00:58 <... epoll_wait resumed> {{EPOLLIN, {u32=8, u64=8}}}, 1024, -1) = 1
18328 17:00:58 rmdir("/path/to/home/myproject/node_modules/gobble/node_modules/promise-map-series" <unfinished ...>
18318 17:00:58 read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
18318 17:00:58 epoll_wait(5,  <unfinished ...>
18326 17:01:01 <... rmdir resumed> )    = -1 ENOTEMPTY (Directory not empty)
18326 17:01:01 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
18318 17:01:01 <... epoll_wait resumed> {{EPOLLIN, {u32=8, u64=8}}}, 1024, -1) = 1
...

在控制台中實時查看時，每個epoll_wait(5,和任何后續輸出之間epoll_wait(5, 3秒鍾的停頓。

Answer 1

供以后參考，根本問題是以下兩個方面的結合：

1. 節點rimraf模塊（使用npm和許多其他包）通過第一試圖刪除一個目錄，並且僅讀出其內容，如果操作rmdir有錯誤ENOTEMPTY （見在此行rimraf源 ）。

2. 我的項目文件夾位於AFS卷上，默認情況下，似乎AFS文件服務器限制了連續發出太多RPC失敗的RPC客戶端（ 麻省理工學院學生信息處理委員會的同事通過電子郵件指出了這一點）。 具體來說，默認值會為連續10多個失敗的RPC設置3秒的延遲。

最終結果是rimraf和依賴它的程序包會緩慢地爬網AFS卷，至少在我的機器上…雖然似乎有操作系統優化可以至少在擊中文件服務器之前使某些命令錯誤（例如， http） ：//milek.blogspot.com/2014/01/mkdir-performance.html ），基於上述日志，我系統上的rmdir似乎沒有發生。

我在這里打開了rimraf問題： https : //github.com/isaacs/rimraf/issues/73

Answer 2

我建議您找到npm uninstall的PID並使用strace或ltrace附加到它：

strace -c -p <PID>

http://linux.die.net/man/1/strace

-c
計算每個系統調用的時間，調用和錯誤，並在程序退出時報告摘要

另外，您可以過濾要跟蹤的呼叫（即文件，網絡，信號等）。

更新：

18318 17:00:52 epoll_wait(5, <unfinished ...>

您可以嘗試向后滾動並找到對epollfd epoll_create()的調用，該調用返回了epollfd == 5 ，該調用隨后傳遞給epoll_wait() 。 檢查其周圍的呼叫可能會提供一些線索。