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

if delete the process but the process's io still used by other process.tell ctr io still in use by other process. #235

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jokemanfire
Copy link
Contributor

find this error in ctr v1.7 "TestContainerDrainExecIOAfterExit" ,if ctr send 'delete' info to shim ,the shim return ok ,the ctr will think that IO is being closed. but this IO may still used by other process , may shim can't close it .

use by other process.tell ctr error.
@Burning1020
Copy link
Member

When failed to delete, shim will return the underlaying error. If IO was used by another process, I think it is the underlaying runtime that should report this error instead of shim.

@jokemanfire
Copy link
Contributor Author

Do you mean to implement it in runc.rs?

@Burning1020
Copy link
Member

Do you mean to implement it in runc.rs?

Not yet, runC command should do this. You can try go-shim and check its behaviour. If go-shim doesn't report, neither of rs-shim.

@jokemanfire
Copy link
Contributor Author

jokemanfire commented Jan 9, 2024

Do you mean to implement it in runc.rs?

Not yet, runC command should do this. You can try go-shim and check its behaviour. If go-shim doesn't report, neither of rs-shim.

I feel confused, Can you provide a solution?the go shim use pipe+fifo , so they can close pipe and fifo will not be used by Daemon , rust-shim use fifo directly, you can't close the io , it will still used by Daemon.this is the different between goshim and rustshim , there's any nice solution to resolve this problem ?

@Burning1020
Copy link
Member

I guess you have a main container that has opened other containers' IO in your case, right? And you expect the other containers shouldn't get removed when their IO is still in use.

@jokemanfire
Copy link
Contributor Author

sorry,I don't think I described it clearly. I find this problem in "TestContainerDrainExecIOAfterExit" from containerd V1.7.6 , it use ExecSync function , but rustshim can not pass this test.

@Burning1020
Copy link
Member

sorry,I don't think I described it clearly. I find this problem in "TestContainerDrainExecIOAfterExit" from containerd V1.7.6 , it use ExecSync function , but rustshim can not pass this test.

OK. Let me check it.

@Wabct
Copy link

Wabct commented Jan 9, 2024

Hi @jokemanfire,I mentioned the same problem in #9568.I thought of a solution, query the process that took the pipe when deleting, and kill then all. But I haven't tested this yet. Can your modification pass “TestContainerDrainExecIOAfterExit”?

@jokemanfire
Copy link
Contributor Author

jokemanfire commented Jan 10, 2024

Hi @jokemanfire,I mentioned the same problem in #9568.I thought of a solution, query the process that took the pipe when deleting, and kill then all. But I haven't tested this yet. Can your modification pass “TestContainerDrainExecIOAfterExit”?

yes, I found your issus and I have mentioned it in rust-shim discussion link ,this code can pass that test, I think you need't kill them ,because containerd will take these io .Another solution (like go shim use pipe + fifo) , also can resolve this problem.

@jokemanfire
Copy link
Contributor Author

Hello , @Burning1020 @Wabct Is there an elegant solution to this problem found? or this issus has been found?Thank you for your reply.... 0.0

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

Successfully merging this pull request may close these issues.

None yet

3 participants