Change:
klog.ErrorS(err, "inotify watcher error") } close(done) <ins> watcher.Close() </ins> }() return nil }

Discussion:
kubelet increased more than 100MB in memory in 4 days. kubelet to not used that amount of RAM I have reproduced it using 3 cronjobs which create hello world pods each minute and another cronjob that writes a line to a file each minute. Kubernetes version (use ): v1.18.1 Cloud provider or hardware configuration happens on both virtualbox and baremetal OS (e.g: ): centos 7 Kernel (e.g. ): 18.0-147.3.1 I have seen some existing issues like but I do not have any dangling resources associated with the cgroup.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
/assign This is a duplicate issue, there has been a fixed PR but it has not been merged.

What happened: i wrote a shell then the kubelet's RSS increases continuously and does not release i make some trace and found some watched objects have never been released even these objects have not existed in real word i notice the fucntion readEvent is producer for these abnormal objects and print the length of every eventsome of which is beyond the length of buf even when i increase the array by 10 timesthe problem is still there and the limits are broken through again and again. so i realized the process of reading cannot be blocked. now i a queue for the buf of every inotify event and another goroutine to consume the queue. everythings seems good for now. What you expected to happen: fixed the bug How to reproduce it (as minimally and precisely as possible): running the shell : Anything else we need to know?: Environment: Kubernetes version (use ):1.17.9 Cloud provider or hardware configuration: OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /area kubelet
/triage unresolved
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
I didn't repeat the question. Is there a way of stable recurrence? Thx!
you could use the shell i'v paste above, or make "add" more faster than "delete".....
/assign
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available .

If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The version mentioned is quite old. Can you please try to repro this on supported version of Kubernetes? /unassign /triage needs-information /remove-triage unresolved
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details