Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process does not terminate after calling stop() #309

Closed
Flamenco opened this issue Nov 16, 2023 · 5 comments
Closed

Process does not terminate after calling stop() #309

Flamenco opened this issue Nov 16, 2023 · 5 comments

Comments

@Flamenco
Copy link
Contributor

Flamenco commented Nov 16, 2023

Issue

I am trying to shutdown my node by calling await helia.stop(), but there are still active timers and listening ports that prevent the process from terminating.

Workaround

call process.exit(0)

Another strategy that worked was to call gc() before stop(). Perhaps stop() should call gc() internally...

await helia.gc()
await helia.stop()

More Information

For your debugging pleasure I am including a dump of open items

open handles:
- File descriptors: (note: stdio always exists)
  - fd 2 (tty) (stdio)
  - fd 1 (tty) (stdio)
  - fd 0 (tty)
- Sockets:
  - 2600:4040:5b06:f300:7c33:3c4f:8cc3:26cf:52501 -> 2602:fea2:2::1:443
- Servers:
  - <unknown address>
    - Listeners:
      - connection: bound onSocket @ file:///Users/steven/dev/projects/ct/ct-labs/projects/helia-test/node_modules/@libp2p/tcp/src/listener.ts:88
  - <unknown address>
    - Listeners:
      - connection: bound onSocket @ file:///Users/steven/dev/projects/ct/ct-labs/projects/helia-test/node_modules/@libp2p/tcp/src/listener.ts:88
- Timers:
  - (5000 ~ 5 s) (anonymous) @ file:///Users/steven/dev/projects/ct/ct-labs/projects/helia-test/node_modules/libp2p/src/connection-manager/auto-dial.ts:107
  - (10000 ~ 10 s) (anonymous) @ node:internal/deps/undici/undici:8364
  - (100 ~ 100 ms) runHeartbeat @ file:///Users/steven/dev/projects/ct/ct-labs/projects/helia-test/node_modules/@chainsafe/libp2p-gossipsub/src/index.ts:598
Unable to determine callsite for "Function". Did you require `wtfnode` at the top of your entry point?
  - (2000 ~ 2 s) (anonymous) @ unknown:0
  - (1000 ~ 1000 ms) later @ file:///Users/steven/dev/projects/ct/ct-labs/projects/helia-test/node_modules/libp2p/src/address-manager/utils.ts:11
  - (84600000 ~ 23 hr) (anonymous) @ file:///Users/steven/dev/projects/ct/ct-labs/projects/helia-test/node_modules/p-timeout/index.js:72
@tuler
Copy link

tuler commented Feb 16, 2024

Im also experiencing this, and calling gc didn’t help

@achingbrain
Copy link
Member

Calling gc is almost certainly a red herring here, all that's going to do is delete any un-pinned blocks from your blockstore, it's not going to affect open TCP sockets.

The reported issue sounds similar to ChainSafe/lodestar#6053 which in turn seemed to be related to libp2p/js-libp2p#2058

That went out in @libp2p/[email protected] - do you still see the issue if you use @libp2p/[email protected] - if not we should probably revert that change.

@SgtPooki SgtPooki closed this as not planned Won't fix, can't repro, duplicate, stale Mar 20, 2024
@Flamenco
Copy link
Contributor Author

Not planning on fixing a resource leak? Hmmmm.

@nflaig
Copy link

nflaig commented Apr 18, 2024

The reported issue sounds similar to ChainSafe/lodestar#6053 which in turn seemed to be related to libp2p/js-libp2p#2058

This is a different issue, see ChainSafe/lodestar#5642. Since we are running libp2p in a worker_thread now I can't tell if this is still there but seems related to ChainSafe/lodestar#5775 which is even more problematic.

@SgtPooki
Copy link
Member

Not planning on fixing a resource leak? Hmmmm.

Normally this issue would be closed as stale because lack of author response. if you have response or remaining concerns, we'd be happy to look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

5 participants