| Summary: | errors while doing parallel docker builds | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jeremy Eder <jeder> |
| Component: | docker | Assignee: | Vivek Goyal <vgoyal> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | atomic-bugs <atomic-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.3 | CC: | dwalsh, lsm5, vgoyal |
| Target Milestone: | rc | Keywords: | Extras |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-19 21:23:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Jeremy Eder
2016-04-21 12:29:04 UTC
I just confirmed this still occurs in docker-1.10: # rpm -q docker-latest docker-latest-1.10.3-11.el7.x86_64 Jermey, so basically build does not fail. You are more concerned that what these messages mean and are they harmful, right? At max these might be leaving some resources behind (if that's happening). After build is successful, do you see leftover images/containers which should not be there? Also can you do "dmsetup table" and see what devices are left behind on the system. I am assuming you are using deferred device removal and deferred device deletion. I have looked at "device-mapper: ioctl: remove_all left 14 open device(s)" message in the past. Its not an error. So don't worry about it. First one seems to be that we try to remove a thin device and it is still busy. Not sure who is using it. But deferred device removal should make sure as soon as user of device goes away, device will be removed. "device-mapper: thin: Deletion of thin device 2142 failed." seems to be new. I will look into it. If build succeeds and at max if we have issue of some resource leak, that does not sound like an "urgent" issue. OSBS has a different clean-up process, but sure, I'll try to catch this in the act. Agree on the urgency, will lower it. Jeremy, what's the kernel version you are using. 3.10.0-327.13.1.el7.x86_64 Jeremy, can you attach the journal logs. I want to go through it and see if something interesting is there. Jeremy, we never went any further with this. Is this still something we should pursue? |