-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zebra_apic threads not started after FRR service restart #16747
Comments
I have been using the following script to reproduce the issue. I have modified the original service file to permit faster restarts so we could see the issue faster, the issue appears with the default configuration as well, if anyone wants to reproduce it using the default configuration you can change the sleep to match the service configuration.
|
As I understand we should see |
If the threads are missing and the owner of the socket is root, then the issue occured. The missing
|
Fixes: FRRouting#16747 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fixes: FRRouting#16747 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Could you test this PR #16749? |
I still see the issue where the |
I looked with a friend at the code and we think that the issue might be in
The above
|
Could you show the whole |
This is the entire content of the
|
Can you reopen it since the issue persists? |
Discussed in #16638
Originally posted by ToshikiRen August 23, 2024
zebra_apic threads not started after FRR service restart (happens after multiple restarts, not all the time, the issue occurrence is mostly random)
The issue is that no routes are sent from routing daemons (e.g., BGP) to the kernel.
Questions:
I managed to reproduce the issue on a box with the following configuration, without configuring BGP peers:
The error from the logs when the issue occurs during restart:
FRR version: 9.1
Show version output:
When the issue occurs the zebra zserv.api socket is owned by root instead of frr:
Looking into the code it seems the only case for root to own this socket would be to use a TCP connection but it is not the case for our configuration.
I have seen this issue on the latest frr release (10.1) as well.
The text was updated successfully, but these errors were encountered: