Skip to content
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

On container exit/termination lfsmount process remains in the process table as defunct #7

Closed
jadolg opened this issue Jun 1, 2020 · 5 comments · Fixed by #9
Closed

Comments

@jadolg
Copy link
Member

jadolg commented Jun 1, 2020

When the container is exited the process remains there until the plugin is disabled.

root      177994  177974  0 11:22 ?        00:00:00 lfsmount /mnt/lizardfs/ -H 10.231.217.39 -P 9421 -S /ppp
root      178467  177974  0 11:22 ?        00:00:00 [lfsmount] <defunct>

I'm guessing I need to somehow detach the parent process from it so it can die without problems.
What do you think @aNeutrino ?

@jadolg
Copy link
Member Author

jadolg commented Jun 1, 2020

This is the same issue as katharostech/docker-plugin_lizardfs#8

@jadolg
Copy link
Member Author

jadolg commented Jun 1, 2020

I was doing some experiments and looks like the way it works will make it hard to even kill the lfsmount application. When I try to kill it after mount it says process already finished.

@zicklag
Copy link
Contributor

zicklag commented Jun 1, 2020

That's a little confusing because the parent process of the zombie should be the Docker plugin process, because that is the process that spawned it. I don't know why the container exiting causes the process to defuct. I could see there being a problem if the plugin container exited and left those processes around.

🤔

I wonder, maybe you could try running the container that is mounting a volume with the --init flag. This will run the tini init system to start the container and reap zombie processes, but still don't think that will work because the zombie was not a child of the container, it was a child of the plugin. Still it's worth a shot.

@jadolg
Copy link
Member Author

jadolg commented Jun 1, 2020

I think I have an idea of what's happening but I'm not completely sure. I think lsfmount is forking itself upon execution and after this point, my application does not know about this process but the system does, so when it dies my application never processes the result and it stays there forever.
My current approach is to try to remove all zombies at some point and I have advanced a bit with this lib https://github.com/ramr/go-reaper
I can already see no defunct processes but now this new dependency is messing the replication goal setting as it kills the process before it's done.
I'll keep you updated.

@zicklag
Copy link
Contributor

zicklag commented Jun 1, 2020

Oh, sweet. Looks like you're making progress. Awesome. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants