[GH-ISSUE #3843] Management server goes down, takes the entire fleet of peers with it #8142

Closed
opened 2026-08-05 01:16:11 -04:00 by saavagebueno · 4 comments
Owner

Originally created by @rihards-simanovics on GitHub (May 19, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/3843

A couple of releases ago, I noticed that when the management server briefly goes down for maintenance (docker restart or upgrade), all peers immediately drop their connection to others, despite showing a P2P connection before that.

When I switched from a traditional VPN to Netbird, I specifically wanted to ensure that if the management peer goes down, this exact scenario doesn't happen. In fact, that was the case when I initially set up Netbird, and it has been that way until fairly recently.

A couple of years ago, the management server went down during the night, but the other peers continued to operate based on their last known configuration from the management server.

Now, when it goes down during the night, so do all of the other peers (mostly Linux and Windows).

The configs have stayed almost the same since the initial setup, with the exception of an occasional sync with the Zitadel installation script from GitHub releases.

I am happy to share the configs from my server if you can specify which ones would be applicable.

Originally created by @rihards-simanovics on GitHub (May 19, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/3843 A couple of releases ago, I noticed that when the management server briefly goes down for maintenance (docker restart or upgrade), all peers immediately drop their connection to others, despite showing a P2P connection before that. When I switched from a traditional VPN to Netbird, I specifically wanted to ensure that if the management peer goes down, this exact scenario doesn't happen. In fact, that was the case when I initially set up Netbird, and it has been that way until fairly recently. A couple of years ago, the management server went down during the night, but the other peers continued to operate based on their last known configuration from the management server. Now, when it goes down during the night, so do all of the other peers (mostly Linux and Windows). The configs have stayed almost the same since the initial setup, with the exception of an occasional sync with the Zitadel installation script from GitHub releases. I am happy to share the configs from my server if you can specify which ones would be applicable.
Author
Owner

@mlsmaycon commented on GitHub (May 19, 2025):

Hello @rihards-simanovics, this should not happen when the management service goes down. Can you please confirm if you are restarting only the management service and not the whole set of services, signal, relays, and coturn?

Also, what is the client version? we had a release (v0.43.0) where the client engine was restarting when management went down.

Can you share some logs of some of the affected nodes (one Windows and one Linux will do) and the time of the last issue?

<!-- gh-comment-id:2891013720 --> @mlsmaycon commented on GitHub (May 19, 2025): Hello @rihards-simanovics, this should not happen when the management service goes down. Can you please confirm if you are restarting only the management service and not the whole set of services, signal, relays, and coturn? Also, what is the client version? we had a release ([v0.43.0](https://github.com/netbirdio/netbird/releases/tag/v0.43.0)) where the client engine was restarting when management went down. Can you share some logs of some of the affected nodes (one Windows and one Linux will do) and the time of the last issue?
Author
Owner

@mlsmaycon commented on GitHub (May 19, 2025):

you can use:

netbird debug bundle -AS -U

this will upload a bundle to our upload site and you just need to share the upload key

<!-- gh-comment-id:2891017494 --> @mlsmaycon commented on GitHub (May 19, 2025): you can use: netbird debug bundle -AS -U this will upload a bundle to our upload site and you just need to share the upload key
Author
Owner

@rihards-simanovics commented on GitHub (May 19, 2025):

Ah, I see it now. The affected servers are indeed running 0.43.0. I'll try to upgrade them and then report back. Thanks for a quick response!

<!-- gh-comment-id:2891260417 --> @rihards-simanovics commented on GitHub (May 19, 2025): Ah, I see it now. The affected servers are indeed running 0.43.0. I'll try to upgrade them and then report back. Thanks for a quick response!
Author
Owner

@rihards-simanovics commented on GitHub (May 19, 2025):

Yep 0.43.0 is indeed the problem, updating to the latest version fixed the issue on the servers.

<!-- gh-comment-id:2891273749 --> @rihards-simanovics commented on GitHub (May 19, 2025): Yep 0.43.0 is indeed the problem, updating to the latest version fixed the issue on the servers.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#8142