Open Bolodya1997 opened 3 years ago
Looks like the cause for this issue is the following: https://github.com/edwarnicke/grpcfd/blob/10fb469a6976e4d488b7a2a66f2a5d09c0d4e43c/connwrap.go#L230-L235
So it results in just closing the file channel, without sending anything: https://github.com/edwarnicke/grpcfd/blob/10fb469a6976e4d488b7a2a66f2a5d09c0d4e43c/connwrap.go#L259-L265
And receiving side doesn't expect channel to be closed: https://github.com/networkservicemesh/sdk/blob/0d2dc281b97c05ed82472a89ceae15cf5122c9e8/pkg/networkservice/common/mechanisms/recvfd/common.go#L60-L72
Event: { File: *os.File, Error: error }
instead of simply sending *os.File
and closing channel on error?@edwarnicke cc
@Bolodya1997 I've fix the panic side of the issue here: https://github.com/networkservicemesh/sdk/pull/910
Looking into why it can happen... we basically only have two potential issues that lead to an error:
Do you still see this error https://github.com/networkservicemesh/sdk/pull/910 applied (admittedly not as a panic, but as an error)? Do you have a notion of why you are seeing it (EBUSY or EMFILE)?
Doesn't seem to be reproducible on kernel
tests, probably need to additionally test with other mechanisms.
@Bolodya1997 Let me know how that goes :)
Env description
Packet automation cluster.
Steps to reproduce
Actual result
VPP forwarder restarts with panic:
Expected result
No restart, no panic.