#docker-dev

has anyone seen this before? https://gist.github.com/erikh/3eb706497101b2f58952

this is against master

reason I'm asking is that I've seen this actually after I've shutdown docker

and only a reboot frees them. I can dig deeper with lsof if nobody knows what's up

[13docker] 15fredlf closed pull request #6731: Update dockerimages.md (06master...06patch-2) 02http://git.io/TKMcAw

[13docker] 15fredlf closed pull request #6680: Update docker-run manpage (06master...06cgroup_memory) 02http://git.io/iW2uQg

the thing is, I think they're getting removed

nope nvm

they aren't

i have some questions/concerns about the ability to do -v /:.. that just landed today... i want this feature in gh#6733 but I think there's some issue that I don't know if are being addressed

Create idiomatic and technically feasible way to mount / into a container: https://github.com/dotcloud/docker/issues/6733

when you mount /, it copies all submounts. so if I'm using aufs, I see all the aufs mount of other containers. the problem though is now those containers that I see their mount, they can't be deleted. because I've effectively remounted the aufs root into my container

crosbymichael: so I wrote this test: https://gist.github.com/erikh/bf1a5007a54bb88f88d7 which I think exhausted the remap problem

alexandr isn't around so I can't ask him to review it

darren0: it does look like we are already using rbind

crosbymichael: am I right to say that if you mount /var your going to shoot yourself in the foot?

on aufs I definitely get other container roots, on btrfs, doesn't seem like so

maybe you can mount a maybe if we do the mount as private or something like that you will not see the recursive mounts

or could be aufs crazyness

well btrfs does not mount

i'm concerned that new ability to mount / is going to mess up a lot of people now as they starting getting a bunch of aufs errors if they ever do mount /

crosbymichael: i just tested on devicemapper, you get other container roots if you do -v /var. so same thing as aufs. is there anyway that we can exclude the mounts from other containers, maybe even after rbind you umount?

thinking... ;)

also it seem that when you hit this issue, the root fails to delete, but the container gets unregistered from docker. so the storage just gets orphaned

darren0: yes, the mounts don't propgate if we don't use rbind

erikh: is that PR ready for review now? nothing going to change?

I don't think anything's going to change. vieux is reviewing it now too.

ok

I'm running docker-stress again

that test nails the real-world problem to the wall, afaict

so I figured out the bind race that I was seeing

TIME_WAIT

I feel like such a fool

either way, if you stop docker-stress for like a minute and restart it (leaving the daemon up), the allocation issues go away. since this is adjustable with sysctl I don't think it's an issue