-
Notifications
You must be signed in to change notification settings - Fork 165
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
Refactor ledd daemon & fix high CPU usage due to unexpected socket close #548
base: master
Are you sure you want to change the base?
Conversation
@Staphylo could you please help review? |
@assrinivasan @vvolam please review |
@prgeor nit: spelling issue in PR description. Also, could you fix the build failure? |
|
||
if state != swsscommon.Select.OBJECT: | ||
self.log_warning("sel.select() did not return swsscommon.Select.OBJECT - May be socket closed???") | ||
return -1 ## Fail here so that the daemon can be restarted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider return code = (128+non-zero-code) per all other daemons code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@assrinivasan do you know the reason for 128+ ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that we use 128+[non-zero code] so that supervisor can restart the daemon. Since your comment in line 118 indicates that the daemon would need to be restarted, I suggested this change.
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
if fvp: | ||
# TODO: Once these flag entries have been removed from the DB, | ||
# we can remove this check | ||
if key in ["PortConfigDone", "PortInitDone"]: | ||
return 3 | ||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we ignoring bad fvp or key not present case now?
…close
Description
[ledd] Refactor ledd daemon and fix high CPU usage due to unexpected redis DB socket close
Motivation and Context
For unkown reason if redis closes the socket, then ledd daemon is continuously busy waiting for socket event and failing all the time. This is resulting in high CPI
How Has This Been Tested?
Close the socket abruptly and see ledd daemon is respawned so that new socket connection is established to redis DB without causing high CPU
Additional Information (Optional)