Docker#delete_container: rescue on "device or resource busy" error

[parkr]

@spraints Not really sure the best way to go about testing this change, but this should help us handle moby/moby#9665.

Hoosegow does automatically attempt to delete the container once the process ends. Would a better option be to sleep 1 and try to delete again? Seems crazy but maybe that’d quell the “resource busy” errors we see.

[spraints]

The begin and end aren't necessary, since this method is so short.

Do you know which other errors delete might raise? I think it'd be fine to swallow any Docker::Error::ServerError. It might be nice to log them.

[spraints]

Would a better option be to sleep 1 and try to delete again?

The containers I looked at were gone from docker, but they were still on disk. So sleep 1 and try again probably wouldn't help, you'd just get a 404 on the retry. In moby/moby#9665, it looks like the files get pretty thoroughly wedged, and need a reboot sometimes to be able to be removed.

[parkr]

@spraints Added a (kind of gross) test and updated the method. Let me know what you think!

[spraints]

This looks ok. 👍 The test doesn't seem to do all that much, since it's all mock interactions. Do you think it's worth keeping the test?

[parkr]

It kept me from forgetting the ::Docker. Not a high-value test but felt bad
submitting a patch without a test.

Matt Burke notifications@github.com schrieb am Sa., 23. Jan. 2016 um
14:45:

This looks ok. [image: 👍] The test doesn't seem to do all that much,
since it's all mock interactions. Do you think it's worth keeping the test?

—
Reply to this email directly or view it on GitHub
#7 (comment).

Parker

[spraints]

It kept me from forgetting the ::Docker. Not a high-value test but felt bad
submitting a patch without a test.

Yeah, that makes sense. Tests that mostly exercise stubs feel weird to me. The ::Docker thing is a good reason to keep the test around. I'll ✂️ a new version 🔜.