I feel more like abandoning that daemon and use a python based implementation.

If the process is simple, you can consider py script. If you need to run uninterrupted in the background or have other complex tasks, it is a good way to continue to use C/C++

Are you familiar with that codebase @jack9603301? As I see no real answer in your posting which does not help at all :(

I have to say that I saw the diff of this code base for the first time, but in fact, as for my understanding of C troubleshooting, analyzing the log and execution process will become a necessary work (none of them). I can see that the operation process required by this code base may be relatively complex, so that it can be executed as a background daemons rather than a single place According to the description of the questioner, there is hardly any relevant information that can be extracted from the error process. It is suggested to provide the following information:

a) Of course, as stated by @c-po, it is necessary to provide its specific configuration

b) Provide a description of the expected results

c) Provide the actual results, such as error report or routing table policy information, and use the most direct command of Linux to explore what exception occurs?

d) Provide conditions for abnormal recurrence so that testers can conduct relevant tests

e) If possible, provide any generated valuable log information about the service

For @c-po, of course, we can't find the root cause of the error from the question post itself, because the questioner lacks the necessary error exploration, so that developers may need to explore the error points by themselves, or have carried out simple exploration, but the amount of information is insufficient. From the questioner's post, except for a diff, I can't see any valuable information, such as log

I have just quickly browsed the relevant code of this code base. Generally speaking, the code structure is very clear, which is not difficult to understand. The overall operation of this daemon is divided into the following processes:

a) check interface address and nexthop

b) Health testing

c) apply rules

d) update output

These operations are carried out continuously in the loop, and the routing table and related policies of iptables are adjusted according to the predetermined rules. However, the key is that the information provided by the questioner is not enough, so it is impossible to determine what link is wrong?

I don’t understand you, is it really impossible to see from the diff that stupid errors have been fixed here?

You mean you've fixed the bug? If so, you can consider submitting pr

I thought you were asking for help and trying to report a bug to the community for a fix, so you need more information to help identify the problem, rather than a diff who doesn't know where to find it

This is worked patches for me. I suggest including my corrections in the main code

If so, you should make it clear that the diff is your own patch. If you are sure that the patch is available in the latest rolling image, you can consider submitting a PR yourself (please refer to the contributor's Guide) to seek consolidation

@jack9603301 the approach from @banditos13 is perfectly fine. Despite the fact that a PR would be the non plus ultra - a problem was identified and a fix was provided - works for me.

Thank you @banditos13

@c-po Please forgive me that I didn't react until it told me that this is a patch. It has solved the problem. In this case, if it is confirmed that the patch is available, then it is not necessary to discuss the cause of the problem. What we need to do is to apply the patch and conduct relevant tests

Thanks