sounisi5011/sounisi5011.jp

ビルドが完了したあともなかなか終了しない

Opened this issue · 6 comments

sounisi5011 commented

環境変数SKIP_NETLIFY_PUB_DATEを指定した以下のビルドコマンド

SKIP_NETLIFY_PUB_DATE=1 DEBUG='@sounisi5011*,metalsmith*' npm run build

を打って開発作業をしていると、サイトのビルドが完了したのに、プロセスがなかなか終了しない問題に襲われる。

当初はmetalsmithが生成するファイルがあまりにも多すぎることによるものと考えたが、ファイルの書き込みが完了していることを確認したため、またファイル生成処理をコメントアウトしても改善しなかったことから原因は別にあると判断。

Node.jsのイベントループが終了していないことが原因と考え、以下の回答を参考に調査を行った。

すると予想通り、process._getActiveHandles()の返り値に以下の内容が存在した：

[ WriteStream {
    connecting: false,
    _hadError: false,
    _handle: [TTY],
    _parent: null,
    _host: null,
    _readableState: [ReadableState],
    readable: false,
    _events: [Object],
    _eventsCount: 2,
    _maxListeners: undefined,
    _writableState: [WritableState],
    writable: true,
    allowHalfOpen: false,
    _sockname: null,
    _pendingData: null,
    _pendingEncoding: '',
    server: null,
    _server: null,
    columns: 202,
    rows: 63,
    _type: 'tty',
    fd: 1,
    _isStdio: true,
    destroySoon: [Function: destroy],
    _destroy: [Function: dummyDestroy],
    [Symbol(asyncId)]: 2,
    [Symbol(lastWriteQueueSize)]: 0,
    [Symbol(timeout)]: null,
    [Symbol(kBytesRead)]: 0,
    [Symbol(kBytesWritten)]: 0 },
  WriteStream {
    connecting: false,
    _hadError: false,
    _handle: [TTY],
    _parent: null,
    _host: null,
    _readableState: [ReadableState],
    readable: false,
    _events: [Object],
    _eventsCount: 2,
    _maxListeners: undefined,
    _writableState: [WritableState],
    writable: true,
    allowHalfOpen: false,
    _sockname: null,
    _pendingData: null,
    _pendingEncoding: '',
    server: null,
    _server: null,
    columns: 202,
    rows: 63,
    _type: 'tty',
    fd: 2,
    _isStdio: true,
    destroySoon: [Function: destroy],
    _destroy: [Function: dummyDestroy],
    [Symbol(asyncId)]: 4,
    [Symbol(lastWriteQueueSize)]: 0,
    [Symbol(timeout)]: null,
    [Symbol(kBytesRead)]: 0,
    [Symbol(kBytesWritten)]: 0 },
  ReadStream {
    connecting: false,
    _hadError: false,
    _handle: [TTY],
    _parent: null,
    _host: null,
    _readableState: [ReadableState],
    readable: true,
    _events: [Object],
    _eventsCount: 2,
    _maxListeners: undefined,
    _writableState: [WritableState],
    writable: false,
    allowHalfOpen: false,
    _sockname: null,
    _pendingData: null,
    _pendingEncoding: '',
    server: null,
    _server: null,
    isRaw: false,
    isTTY: true,
    fd: 0,
    [Symbol(asyncId)]: 12,
    [Symbol(lastWriteQueueSize)]: 0,
    [Symbol(timeout)]: null,
    [Symbol(kBytesRead)]: 0,
    [Symbol(kBytesWritten)]: 0 },
  Socket {
    connecting: false,
    _hadError: false,
    _handle: [TCP],
    _parent: null,
    _host: 'mirrors.creativecommons.org',
    _readableState: [ReadableState],
    readable: true,
    _events: [Object],
    _eventsCount: 6,
    _maxListeners: undefined,
    _writableState: [WritableState],
    writable: true,
    allowHalfOpen: false,
    _sockname: null,
    _pendingData: null,
    _pendingEncoding: '',
    server: null,
    _server: null,
    parser: null,
    _httpMessage: [ClientRequest],
    [Symbol(asyncId)]: 1082,
    [Symbol(lastWriteQueueSize)]: 0,
    [Symbol(timeout)]: null,
    [Symbol(kBytesRead)]: 0,
    [Symbol(kBytesWritten)]: 0 },
  Socket {
    connecting: false,
    _hadError: false,
    _handle: [TCP],
    _parent: null,
    _host: 'mirrors.creativecommons.org',
    _readableState: [ReadableState],
    readable: true,
    _events: [Object],
    _eventsCount: 6,
    _maxListeners: undefined,
    _writableState: [WritableState],
    writable: true,
    allowHalfOpen: false,
    _sockname: null,
    _pendingData: null,
    _pendingEncoding: '',
    server: null,
    _server: null,
    parser: null,
    _httpMessage: [ClientRequest],
    [Symbol(asyncId)]: 1093,
    [Symbol(lastWriteQueueSize)]: 0,
    [Symbol(timeout)]: null,
    [Symbol(kBytesRead)]: 0,
    [Symbol(kBytesWritten)]: 0 } ]

おそらく、これが生きている原因だろう。どこかのファイルI/Oか、ネットワークが繋がったままになっているに違いない。

sounisi5011 commented

#104 (comment) で報告された出力内容にはmirrors.creativecommons.orgというドメイン名が含まれている。これは、以下のファイルに含まれている：

*.downloadファイルは@sounisi5011/metalsmith-download-conventionによって処理されるものであり、このプラグインはdownload@7.1.0パッケージを用いてファイルをダウンロードしている。

このパッケージは新しいバージョンのdownload@8.0.0が公開されているため、もしかするとこの問題が解決する可能性がある。

sounisi5011 commented

#104 (comment) で報告された出力内容にはmirrors.creativecommons.orgというドメイン名が含まれている。これは、以下のファイルに含まれている：

*.downloadファイルは@sounisi5011/metalsmith-download-conventionによって処理されるものであり、このプラグインはdownload@7.1.0パッケージを用いてファイルをダウンロードしている。

このパッケージは新しいバージョンのdownload@8.0.0が公開されているため、もしかするとこの問題が解決する可能性がある。

─ #104 (comment)

結論を言えば、@sounisi5011/metalsmith-download-conventionのコメントアウトにより解決した。process._getActiveHandles()の返り値にはReadStreamとWriteStreamが含まれていたものの、ビルドの完了直後にプロセスは正常終了した。やはり、download@7.1.0パッケージに問題があるように思われる。

sounisi5011 commented

#104 (comment) で報告された出力内容にはmirrors.creativecommons.orgというドメイン名が含まれている。これは、以下のファイルに含まれている：

*.downloadファイルは@sounisi5011/metalsmith-download-conventionによって処理されるものであり、このプラグインはdownload@7.1.0パッケージを用いてファイルをダウンロードしている。
このパッケージは新しいバージョンのdownload@8.0.0が公開されているため、もしかするとこの問題が解決する可能性がある。
─ #104 (comment)

結論を言えば、@sounisi5011/metalsmith-download-conventionのコメントアウトにより解決した。process._getActiveHandles()の返り値にはReadStreamとWriteStreamが含まれていたものの、ビルドの完了直後にプロセスは正常終了した。やはり、download@7.1.0パッケージに問題があるように思われる。

─ #104 (comment)

downloadパッケージのcacheオプションをコメントアウトしたところ、速度が改善した。おそらく原因はキャッシュファイルの生成だろう。

sounisi5011 commented

#104 (comment) で報告された出力内容にはmirrors.creativecommons.orgというドメイン名が含まれている。これは、以下のファイルに含まれている：

*.downloadファイルは@sounisi5011/metalsmith-download-conventionによって処理されるものであり、このプラグインはdownload@7.1.0パッケージを用いてファイルをダウンロードしている。
このパッケージは新しいバージョンのdownload@8.0.0が公開されているため、もしかするとこの問題が解決する可能性がある。
─ #104 (comment)

結論を言えば、@sounisi5011/metalsmith-download-conventionのコメントアウトにより解決した。process._getActiveHandles()の返り値にはReadStreamとWriteStreamが含まれていたものの、ビルドの完了直後にプロセスは正常終了した。やはり、download@7.1.0パッケージに問題があるように思われる。
─ #104 (comment)

downloadパッケージのcacheオプションをコメントアウトしたところ、速度が改善した。おそらく原因はキャッシュファイルの生成だろう。

keyv-file@0.1.13内の生成済みのキャッシュファイルを読み込む処理をコメントアウトしたところ、速度が改善した。ただし、キャッシュファイルを読み込むfs. readFileSync()関数および（内部でJSON.parse()を使用している）this._opts.decode()を残しても速度は改善したため、ファイルI/OおよびJSONの変換処理が原因ではない。すでに存在するキャッシュの内容をMapオブジェクトに展開した場合に、速度の問題が発生する。

sounisi5011 commented

内部処理の問題だとしたら…こいつぁ根深いぞ…
どうせならkeyv-file-binaryみたいなやつ書きたい。

sounisi5011 commented

もしかしたらlevelが使えるかもしれない。ただし：