[GH-ISSUE #5229] Client disconnects repeatedly with "ResourceExhausted: too many concurrent sync requests" on macOS #10836

Closed
opened 2026-08-05 01:27:28 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @fanmaomao on GitHub (Feb 1, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5229

Describe the problem

The Netbird client successfully connects initially but then enters a loop of disconnections and reconnections. The logs show repeated ResourceExhausted errors from the Management Service sync stream, followed by wrongly addressed message errors from the Signal worker.

To Reproduce

  1. Run sudo netbird up -F -l debug
  2. Wait for the connection to establish.
  3. Observe the logs after a few seconds.

Are you using NetBird Cloud?

Yes

NetBird version

0.64.3

Debug output
netbird up -F -l debug:

2026-02-01T16:36:49+08:00 INFO client/internal/connect.go:133: starting NetBird client version 0.64.3 on darwin/arm64
...
2026-02-01T16:37:01+08:00 INFO [relay: rels://relay.netbird.io:443] shared/relay/client/client.go:168: create new relay connection: local peerID: <REDACTED_PEER_ID>, local peer hashedID: <REDACTED_HASH>
...
2026-02-01T16:37:04+08:00 INFO client/internal/engine.go:273: I am: <REDACTED_PEER_ID>
...
2026-02-01T16:37:04+08:00 DEBG client/internal/routemanager/systemops/systemops_generic.go:352: Route for 0.0.0.0: interface &{15 1500 en1 <REDACTED_MAC> up|broadcast|multicast|running} nexthop 192.168.x.1, preferred source 192.168.x.x
...
2026-02-01T16:37:20+08:00 INFO client/internal/connect.go:329: Netbird engine started, the IP is: 100.126.x.x/16
...
2026-02-01T16:37:21+08:00 ERRO shared/signal/client/worker.go:46: failed to handle message: wrongly addressed message <REDACTED_MSG_HASH>
2026-02-01T16:37:23+08:00 INFO shared/management/client/grpc.go:318: connected to the Management Service stream
2026-02-01T16:37:23+08:00 DEBG shared/management/client/grpc.go:182: job stream handshake sent successfully
2026-02-01T16:37:23+08:00 DEBG shared/management/client/grpc.go:416: disconnected from Management Service sync stream: rpc error: code = ResourceExhausted desc = too many concurrent sync requests, please try again later
2026-02-01T16:37:23+08:00 WARN shared/management/client/grpc.go:333: disconnected from the Management service but will retry silently. Reason: rpc error: code = ResourceExhausted desc = too many concurrent sync requests, please try again later
...
(Repeated ResourceExhausted errors continue...)

netbird debug for 1m -AS -U:

Upload file key:
f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffaxxxx/928f8cd7-47bf-4900-xxxx-xxxx
Originally created by @fanmaomao on GitHub (Feb 1, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5229 **Describe the problem** The Netbird client successfully connects initially but then enters a loop of disconnections and reconnections. The logs show repeated ResourceExhausted errors from the Management Service sync stream, followed by wrongly addressed message errors from the Signal worker. **To Reproduce** 1. Run sudo `netbird up -F -l debug` 2. Wait for the connection to establish. 3. Observe the logs after a few seconds. **Are you using NetBird Cloud?** Yes **NetBird version** `0.64.3` **Debug output** `netbird up -F -l debug`: ``` 2026-02-01T16:36:49+08:00 INFO client/internal/connect.go:133: starting NetBird client version 0.64.3 on darwin/arm64 ... 2026-02-01T16:37:01+08:00 INFO [relay: rels://relay.netbird.io:443] shared/relay/client/client.go:168: create new relay connection: local peerID: <REDACTED_PEER_ID>, local peer hashedID: <REDACTED_HASH> ... 2026-02-01T16:37:04+08:00 INFO client/internal/engine.go:273: I am: <REDACTED_PEER_ID> ... 2026-02-01T16:37:04+08:00 DEBG client/internal/routemanager/systemops/systemops_generic.go:352: Route for 0.0.0.0: interface &{15 1500 en1 <REDACTED_MAC> up|broadcast|multicast|running} nexthop 192.168.x.1, preferred source 192.168.x.x ... 2026-02-01T16:37:20+08:00 INFO client/internal/connect.go:329: Netbird engine started, the IP is: 100.126.x.x/16 ... 2026-02-01T16:37:21+08:00 ERRO shared/signal/client/worker.go:46: failed to handle message: wrongly addressed message <REDACTED_MSG_HASH> 2026-02-01T16:37:23+08:00 INFO shared/management/client/grpc.go:318: connected to the Management Service stream 2026-02-01T16:37:23+08:00 DEBG shared/management/client/grpc.go:182: job stream handshake sent successfully 2026-02-01T16:37:23+08:00 DEBG shared/management/client/grpc.go:416: disconnected from Management Service sync stream: rpc error: code = ResourceExhausted desc = too many concurrent sync requests, please try again later 2026-02-01T16:37:23+08:00 WARN shared/management/client/grpc.go:333: disconnected from the Management service but will retry silently. Reason: rpc error: code = ResourceExhausted desc = too many concurrent sync requests, please try again later ... (Repeated ResourceExhausted errors continue...) ``` `netbird debug for 1m -AS -U`: ``` Upload file key: f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffaxxxx/928f8cd7-47bf-4900-xxxx-xxxx ```
saavagebueno added the triage-needed label 2026-08-05 01:27:28 -04:00
Author
Owner

@fanmaomao commented on GitHub (Feb 1, 2026):

Additional Context: Session Expiry Anomaly and Potential Link to Hostname Changes

I have additional information that might help pinpoint the root cause. I have two Mac Minis (Home and Office). While the ResourceExhausted issue was captured on my Home Mac, I found the following broadcast messages on my Office Mac today:

Broadcast Message from root@Mac-mini-2.local
        (no tty) at 23:45 CST...
NetBird connection session expired
Please re-authenticate to connect to the network.

Key Anomalies:

"Never Expire" Bypassed: I am 100% certain that "Peer Login Expiration" is disabled for this Office Mac in the dashboard. Despite this, the client reported a session expiry and disconnected.

Hostname Changes: I recently modified the hostname on both Mac Minis (though I don't recall the exact previous values).

Recovery Behavior: The Office Mac lost internet/network access entirely. However, after running netbird down and netbird up, the connection was restored. Interestingly, as soon as the Office Mac reconnected, I noticed on the dashboard( https://app.netbird.io/peers ) that both the Home and Office Macs were back online.

Version Info: The Office Mac is running NetBird version 0.36.5.

My Hypothesis: There seems to be a synchronization logic error triggered by hostname changes. It appears the client enters an invalid state where the Management Server either misidentifies the peer or forces a session termination (ignoring the "Never Expire" setting). This might be the same underlying state-sync loop that causes the ResourceExhausted error on my other machine.

<!-- gh-comment-id:3832583126 --> @fanmaomao commented on GitHub (Feb 1, 2026): **Additional Context: Session Expiry Anomaly and Potential Link to Hostname Changes** I have additional information that might help pinpoint the root cause. I have two Mac Minis (Home and Office). While the ResourceExhausted issue was captured on my **Home Mac**, I found the following broadcast messages on my **Office Mac** today: ``` Broadcast Message from root@Mac-mini-2.local (no tty) at 23:45 CST... NetBird connection session expired Please re-authenticate to connect to the network. ``` **Key Anomalies**: **"Never Expire" Bypassed**: I am **100%** certain that "Peer Login Expiration" is **disabled** for this Office Mac in the dashboard. Despite this, the client reported a session expiry and disconnected. **Hostname Changes**: I recently modified the hostname on both Mac Minis (though I don't recall the exact previous values). **Recovery Behavior**: The Office Mac lost internet/network access entirely. However, after running netbird down and netbird up, the connection was restored. Interestingly, as soon as the Office Mac reconnected, I noticed on the dashboard( https://app.netbird.io/peers ) that both the Home and Office Macs were back online. **Version Info**: The Office Mac is running NetBird version **0.36.5**. My Hypothesis: There seems to be a synchronization logic error triggered by hostname changes. It appears the client enters an invalid state where the Management Server either misidentifies the peer or forces a session termination (ignoring the "Never Expire" setting). This might be the same underlying state-sync loop that causes the ResourceExhausted error on my other machine.
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#10836