Close can hang and leak the WireGuard engine and DERP connection: bump tailscale.com past the netstack close fix, and close the backend regardless

オープン
  • 何か問題がありますか？
#151 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@ryjen がすでに取り組んでいます。

2026年10月20日 から。

  • #3 @ryjen による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
backend, networking

調査の方向性

Start with locoBackend.Close in tailcat.go (around lines 374-392), where the WireGuard engine, network monitor, dialer and event bus only close after ns.Close() returns, and with Client.Close (around lines 2003-2010), which holds startMu across lb.Close. Bumping the tailscale.com version in go.mod is the first step, and the backend-teardown change needs a test that makes netstack close block. Done means a close that hangs in the netstack still releases the remaining resources and does not block other Client use. The TCP option and abortive-close requests are API design and should be scoped separately.

索引モデルが issue の本文から書いたものです。

説明

What is the issue?

Tailcat v0.7.0 requires tailscale.com v1.103.0-pre.0.20260916030321-a2263542f260, and main (52fbad3) requires v1.103.0-pre.0.20260929142145-a0e471a35b8f. Both predate tailscale/tailscale#21668 (merged as fb79793 on 2026-10-13), which fixes tailscale/tailscale#21631: wgengine/netstack.(*Impl).Close blocks forever once more TCP endpoints need a reset than its 512-packet outbound queue holds.

We hit that through Tailcat. A Server holding 497 endpoints in TIME-WAIT closed in about 1 ms; one holding 539 never returned. A server that carried a few hundred short connections in the last minute is enough, since gVisor keeps TIME-WAIT for 60 s.

Requests, roughly in order of value:

  1. Bump tailscale.com past fb79793.
  2. Close the rest of the backend even when the netstack's close blocks. locoBackend.Close (tailcat.go:374-392, v0.7.0) closes the WireGuard engine, the network monitor, the dialer and the event bus only after ns.Close() returns. When that blocks, the process keeps the magicsock UDP sockets, the DERP connection (with its keepalive every 60 to 65 s, reconnecting after each relay restart) and their goroutines until it exits. Measured per stuck Client: about 104 goroutines, 7.5 MiB of live heap and one DERP connection. A program that closes a Client whenever a peer goes away leaks one of these per peer change.
  3. Client.Close holds startMu across lb.Close (tailcat.go:2003-2010), so a close stuck in the backend also blocks any concurrent use of that Client.
  4. A way to set the netstack's TCP options, at least tcpip.TCPTimeWaitTimeoutOption. tailscale.com's netstack.Impl already has SetTransportProtocolOption; a Server/Client field for the TIME-WAIT timeout, or the accessor the TODO at tcpipStackOf (tailcat.go:960-963) asks for, would do.
  5. Optionally, an exported abortive close (linger 0) for the conns Tailcat returns. Related to google/gvisor#15013: Server accepts through tcp.Forwarder, and gVisor drops a new SYN on a 4-tuple the server still holds in TIME-WAIT until TIME-WAIT expires. A client that makes one short connection per request, with the server closing first, sees about 60 x R / 49,536 of its dials stall (R connections a second over one client/server pair): we measured 2.4% at 20/s, 9.7% at 80/s and 36% at 300/s, each stalled dial waiting out the caller's timeout. Setting linger 0 on the client's conn before closing it (through gonet's unexported ep, the field Tailcat's own gonetTCPConnInternals reads) removed the stalls and left no TIME-WAIT on either side: 60,000 short connections over one pair in 4.2 s, none failed. An exported option would avoid the reflection.
Environment

Tailcat v0.7.0; tailscale.com v1.103.0-pre.0.20260916030321-a2263542f260; gVisor v0.0.0-20260915211658-a6f909f08a72; Go 1.27.2; Linux (Docker 29.8) and macOS. Measured with Tailcat's Server and Client in one process over an in-process relay, and between containers.

主要言語
Go
スター
8.8k
フォーク
404
平均マージ
3時間 48分
マージ済み PR（30日）
1

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

tailscale/tailcat のほかの issue

tailscale/tailcat の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。