[BugFix] Threadsafe close async zmq sockets

[njhill]

FIX #22831
FIX #22839

• Ensure async zmq sockets are closed from the event loop
• Set LINGER=0 on stats update sockets to ensure they don't block the context being closed

[gemini-code-assist]

Code Review

This pull request addresses a potential hanging issue when closing asynchronous ZMQ sockets by ensuring they are closed from within their event loop. The changes introduce a close_sockets helper function and modify the BackgroundResources finalizer to use loop.call_soon_threadsafe for closing async sockets and cancelling related tasks. This is the correct approach for thread-safe cleanup of asyncio resources. Additionally, linger=0 is set on stats update sockets to prevent them from blocking context termination. The changes appear correct and well-implemented to fix the described bug.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

🚀

[DarkLight1337]

Unblocking 4 GPUs test

[DarkLight1337]

Passed as well, merging

[njhill]

@Isotr0py you probably saw, I incorporated your changes after all for explicitly closing the other sockets because they did appear to be needed. I wasn't able to reproduce locally but the CI test was still hanging without them.

[Isotr0py]

Yes, I can't reproduce the hanging issue locally but it will stuck at gc.collect for about 3~5 mins:

Current thread 0x0000792424c13740 (most recent call first):
  Garbage-collecting
  File "/kaggle/working/vllm/.venv/lib/python3.12/site-packages/zmq/sugar/context.py", line 264 in term
  File "/kaggle/working/vllm/.venv/lib/python3.12/site-packages/zmq/sugar/context.py", line 322 in destroy
  File "/kaggle/working/vllm/.venv/lib/python3.12/site-packages/zmq/sugar/context.py", line 140 in __del__
  File "/kaggle/working/vllm/vllm/distributed/parallel_state.py", line 1277 in cleanup_dist_env_and_memory
  File "/kaggle/working/vllm/tests/conftest.py", line 199 in cleanup_fixture
  File "/kaggle/working/vllm/.venv/lib/python3.12/site-packages/_pytest/fixtures.py", line 907 in _teardown_yield_fixture

I wonder if there are some issues at ZMQ side...