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.
Due to the name of the function I was expected to see a wait4 syscall to consume the child process, in our case goofys.
If we look at the below outputs:
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.
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
https://github.com/ctrox/csi-s3/blob/ddbd6fdaa1bd76754df3ea76fba0afe149ebe87d/pkg/mounter/mounter.go#L133-L156Due 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. https://github.com/ctrox/csi-s3/blob/ddbd6fdaa1bd76754df3ea76fba0afe149ebe87d/pkg/mounter/mounter.go#L142-L148wdyt @ctrox?