-
Notifications
You must be signed in to change notification settings - Fork 171
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
defunct processes, the possible explanation #74
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
introduction
The following explanation is focused on using csi-s3 with
goofys
as a backend. All the components are in their latest version.The issue I stumbled upon is the number of goofys Zombie processes.
The number doesn't have any importance in the understanding.
explanation
I looked in the csi-s3 code and more importantly at the
FuseUnmount
function and then atwaitForProcess
csi-s3/pkg/mounter/mounter.go
Lines 133 to 156 in ddbd6fd
Due to the name of the function I was expected to see a
wait4
syscall to consume the child process, in our casegoofys
.If we look at the below outputs:
goofys
Zombie process withpid=32767
As s3driver launches
goofys
backend (I guess it is the case for the other backends 🤷🏼♂️), s3driver is the parent process. Then as a good parent 😃 it should wait4 its child to know what was its status.In other words, there is a leak on child termination. The fix should be trivial; in the
waitForProcess
when thecmdLine
is empty, we have tosyscall.wait4
on the given pid.csi-s3/pkg/mounter/mounter.go
Lines 142 to 148 in ddbd6fd
wdyt @ctrox?
The text was updated successfully, but these errors were encountered: