Closed yupi closed 6 years ago
@yupi Hi, Hmmm... this issue seems to be related to the implementation of Dynamic Neighbor, but I guess it should be a rare case (timing seems to be severe). Is this issue occurred often?
The cause of this issue is Peer.outgoing *channels.InfiniteChannel
is doubly closed when restarting a Peer instance for the Dynamic Neighbor, but this channel should re-instantiated right after closed like;
https://github.com/osrg/gobgp/blob/38223f2f512cce3d05c9ae8f29ade983aa723cef/server/server.go#L921-L928
Just a workaround (not graceful way in Golang), the following fixes this issue?
diff --git a/server/util.go b/server/util.go
index b122fbd..f401b23 100644
--- a/server/util.go
+++ b/server/util.go
@@ -22,11 +22,21 @@ import (
"syscall"
"github.com/eapache/channels"
+ log "github.com/sirupsen/logrus"
"github.com/osrg/gobgp/packet/bgp"
)
func cleanInfiniteChannel(ch *channels.InfiniteChannel) {
+ // Avoid panic when InfiniteChannel is already closed
+ defer func() {
+ if err := recover(); err != nil {
+ log.WithFields(log.Fields{
+ "Topic": "Server",
+ }).Warn("failed to close InfiniteChannel: ", err)
+ }
+ }()
+
ch.Close()
// drain all remaining items
for range ch.Out() {
recover() is the last resort so need to fix in a different way.
@yupi The bug is a race related with the dynamic neighbor feature. We fixed it. I've just released the new version including the fix so please try: https://github.com/osrg/gobgp/releases/tag/v1.28
Thanks, will do tests today.
I set up my rpi as a route reflector using https://github.com/osrg/gobgp/releases/download/v1.27/gobgp_1.27_linux_armv6.tar.gz binary with a peer on my macbook. In the morning after i awaked my macbook i found GoBGP crashed after the peer goes down. Here is the log and the trace:
My RR config is