docker 1.4 and "Driver aufs failed to remove root filesystem",  "device or resource busy"

I don't think I saw this under docker 1.3.x on aufs (boot2docker on OSX), though I have with devicemapper on centos server. Got this error after upgrading docker server, retrying the fig up worked.
I use brew and my docker client is still 1.3.2. Just saw the warning in the log below, I guess that's not really supported?
Recreating dns_dnsmasq_1...
Cannot destroy container 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: Driver aufs failed to remove root filesystem 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: rename /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727 /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727-removing: device or resource busy

time="2014-12-14T20:21:27Z" level="info" msg="Container 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727 failed to exit within 10 seconds of SIGTERM - using the force"
time="2014-12-14T20:21:27Z" level="debug" msg="Sending 9 to 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727"
time="2014-12-14T20:21:28Z" level="info" msg="+job log(die, 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727, dns_dnsmasq:latest)"
time="2014-12-14T20:21:28Z" level="info" msg="-job log(die, 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727, dns_dnsmasq:latest) = OK (0)"
time="2014-12-14T20:21:28Z" level="info" msg="+job release_interface(07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727)"
...
time="2014-12-14T20:21:29Z" level="debug" msg="Calling DELETE /containers/{name:.*}"
time="2014-12-14T20:21:29Z" level="info" msg="DELETE /v1.12/containers/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727?link=False&force=False&v=False"
time="2014-12-14T20:21:29Z" level="info" msg="+job rm(07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727)"
Cannot destroy container 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: Driver aufs failed to remove root filesystem 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: r
ename /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727 /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727
-removing: device or resource busy
time="2014-12-14T20:21:29Z" level="info" msg="-job rm(07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727) = ERR (1)"
time="2014-12-14T20:21:29Z" level="error" msg="Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: Driver a
ufs failed to remove root filesystem 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: rename /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9
dd727 /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727-removing: device or resource busy"
time="2014-12-14T20:21:29Z" level="error" msg="HTTP Error: statusCode=500 Cannot destroy container 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: Driver aufs failed to remove root file
system 07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727: rename /mnt/sda1/var/lib/docker/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727 /mnt/sda1/var/lib/docker
/aufs/mnt/07ba11ca55a87ec6556a27007dd56a42da370ed8d78b34aed2f573266e9dd727-removing: device or resource busy"
time="2014-12-14T20:24:15Z" level="debug" msg="Calling POST /containers/{name:.*}/exec"
time="2014-12-14T20:24:15Z" level="info" msg="POST /v1.15/containers/dns_dnsmasq_1/exec"
time="2014-12-14T20:24:15Z" level="debug" msg="Warning: client and server don't have the same version (client: 1.3.2, server: 1.4.0)"

I'm seeing the same issue on 1.4.1.
$ docker info
Containers: 1
Images: 11
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Dirs: 17
Execution Driver: native-0.2
Kernel Version: 3.16.7-tinycore64
Operating System: Boot2Docker 1.4.1 (TCL 5.4); master : 86f7ec8 - Tue Dec 16 23:11:29 UTC 2014
CPUs: 8
Total Memory: 1.961 GiB
Name: boot2docker
ID: LBNP:H3GO:XVDK:GTCP:FNOX:OPY4:QJUP:QIKK:HAKK:TABZ:3NP6:4N7S
Debug mode (server): true
Debug mode (client): false
Fds: 17
Goroutines: 18
EventsListeners: 0
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker

I'm seeing this too on Docker 1.4.1.
I perform periodic health checks using ephemeral containers attached to the target container's network (via the --net container:xyz flag). It seems that one of these containers started nearly at the moment target container died. This may be somehow related to the issue, but I'm not sure.
Here is the related log (I replaced ids of target and check containers with TARGET and CHECK for clarity):
//
// Creating container TARGET
// docker run -it --rm -p <IP_ADDRESS>:4000:3000 test-app
//

time="2015-01-20T19:36:17Z" level="info" msg="POST /v1.16/containers/create"
time="2015-01-20T19:36:17Z" level="info" msg="+job create()"
time="2015-01-20T19:36:17Z" level="info" msg="+job log(create, TARGET, test-app:latest)"
time="2015-01-20T19:36:17Z" level="info" msg="-job log(create, TARGET, test-app:latest) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="-job create() = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="POST /v1.16/containers/TARGET/attach?stderr=1&stdin=1&stdout=1&stream=1"
time="2015-01-20T19:36:17Z" level="info" msg="+job container_inspect(TARGET)"
time="2015-01-20T19:36:17Z" level="info" msg="-job container_inspect(TARGET) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="+job attach(TARGET)"
time="2015-01-20T19:36:17Z" level="info" msg="POST /v1.16/containers/TARGET/start"
time="2015-01-20T19:36:17Z" level="info" msg="+job start(TARGET)"
time="2015-01-20T19:36:17Z" level="info" msg="+job allocate_interface(TARGET)"
time="2015-01-20T19:36:17Z" level="info" msg="-job allocate_interface(TARGET) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="+job allocate_port(TARGET)"
time="2015-01-20T19:36:17Z" level="info" msg="-job allocate_port(TARGET) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="+job log(start, TARGET, test-app:latest)"
time="2015-01-20T19:36:17Z" level="info" msg="-job log(start, TARGET, test-app:latest) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="GET /containers/TARGET/json"
time="2015-01-20T19:36:17Z" level="info" msg="+job container_inspect(TARGET)"
time="2015-01-20T19:36:17Z" level="info" msg="-job start(TARGET) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="-job container_inspect(TARGET) = OK (0)"
time="2015-01-20T19:36:17Z" level="info" msg="POST /v1.16/containers/TARGET/resize?h=25&w=180"
time="2015-01-20T19:36:17Z" level="info" msg="+job resize(TARGET, 25, 180)"
time="2015-01-20T19:36:17Z" level="info" msg="-job resize(TARGET, 25, 180) = OK (0)"

// ... (unrelated log skipped)
//
// Creating and starting ephemeral check container CHECK
// docker run --name chk-N --net container:TARGET check-img some_check_command
//

time="2015-01-20T19:36:46Z" level="info" msg="POST /v1.16/containers/create?name=chk-N"
time="2015-01-20T19:36:46Z" level="info" msg="+job create(chk-N)"
time="2015-01-20T19:36:46Z" level="info" msg="+job log(create, CHECK, consul:latest)"
time="2015-01-20T19:36:46Z" level="info" msg="-job log(create, CHECK, consul:latest) = OK (0)"
time="2015-01-20T19:36:46Z" level="info" msg="-job create(chk-N) = OK (0)"
time="2015-01-20T19:36:46Z" level="info" msg="POST /v1.16/containers/CHECK/attach?stderr=1&stdout=1&stream=1"
time="2015-01-20T19:36:46Z" level="info" msg="+job container_inspect(CHECK)"
time="2015-01-20T19:36:46Z" level="info" msg="-job container_inspect(CHECK) = OK (0)"
time="2015-01-20T19:36:46Z" level="info" msg="+job attach(CHECK)"
time="2015-01-20T19:36:46Z" level="info" msg="POST /v1.16/containers/CHECK/start"
time="2015-01-20T19:36:46Z" level="info" msg="+job start(CHECK)"
time="2015-01-20T19:36:46Z" level="info" msg="+job log(start, CHECK, consul:latest)"
time="2015-01-20T19:36:46Z" level="info" msg="-job log(start, CHECK, consul:latest) = OK (0)"

//
// Target container died
//

time="2015-01-20T19:36:47Z" level="info" msg="+job log(die, TARGET, test-app:latest)"
time="2015-01-20T19:36:47Z" level="info" msg="-job log(die, TARGET, test-app:latest) = OK (0)"
time="2015-01-20T19:36:47Z" level="info" msg="+job release_interface(TARGET)"

time="2015-01-20T19:36:47Z" level="info" msg="GET /containers/CHECK/json"
time="2015-01-20T19:36:47Z" level="info" msg="+job container_inspect(CHECK)"

time="2015-01-20T19:36:47Z" level="info" msg="-job attach(TARGET) = OK (0)"
time="2015-01-20T19:36:47Z" level="info" msg="POST /v1.16/containers/TARGET/wait"
time="2015-01-20T19:36:47Z" level="info" msg="+job wait(TARGET)"
time="2015-01-20T19:36:47Z" level="info" msg="-job release_interface(TARGET) = OK (0)"
time="2015-01-20T19:36:47Z" level="info" msg="-job wait(TARGET) = OK (0)"
time="2015-01-20T19:36:47Z" level="info" msg="GET /v1.16/containers/TARGET/json"
time="2015-01-20T19:36:47Z" level="info" msg="+job container_inspect(TARGET)"
time="2015-01-20T19:36:47Z" level="info" msg="-job container_inspect(TARGET) = OK (0)"

//
// Removing target container (as a consequence of --rm cli flag)
//

time="2015-01-20T19:36:47Z" level="info" msg="DELETE /v1.16/containers/TARGET?v=1"
time="2015-01-20T19:36:47Z" level="info" msg="+job rm(TARGET)"

//
// Error: device or resource busy. This is not OK.
 This is OK.
//

time="2015-01-20T19:36:47Z" level="info" msg="+job release_interface(CHECK)"
No network information to release for CHECK
time="2015-01-20T19:36:47Z" level="info" msg="-job release_interface(CHECK) = ERR (1)"
time="2015-01-20T19:36:47Z" level="info" msg="-job attach(CHECK) = OK (0)"
time="2015-01-20T19:36:47Z" level="info" msg="+job release_interface(CHECK)"
No network information to release for CHECK
time="2015-01-20T19:36:47Z" level="info" msg="-job release_interface(CHECK) = ERR (1)"
time="2015-01-20T19:36:47Z" level="info" msg="+job log(die, CHECK, consul:latest)"
time="2015-01-20T19:36:47Z" level="info" msg="-job log(die, CHECK, consul:latest) = OK (0)"
Cannot start container CHECK: setup networking failed get network namespace fd: open /proc/10959/ns/net: no such file or directory
time="2015-01-20T19:36:47Z" level="info" msg="-job start(CHECK) = ERR (1)"
time="2015-01-20T19:36:47Z" level="error" msg="Handler for POST /containers/{name:.*}/start returned error: Cannot start container CHECK: setup networking failed get network namespace fd: open /proc/10959/ns/net: no such file or directory"
time="2015-01-20T19:36:47Z" level="error" msg="HTTP Error: statusCode=404 Cannot start container CHECK: setup networking failed get network namespace fd: open /proc/10959/ns/net: no such file or directory"

Docker version & info:
$ docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): darwin/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

$ docker info
Containers: 5
Images: 105
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Dirs: 117
Execution Driver: native-0.2
Kernel Version: 3.16.7-tinycore64
Operating System: Boot2Docker 1.4.1 (TCL 5.4); master : 86f7ec8 - Tue Dec 16 23:11:29 UTC 2014
CPUs: 4
Total Memory: 1.961 GiB
Name: boot2docker
ID: LP33:7HWL:DFI6:5AL5:RNBL:D5ZJ:AMGD:WO3I:DGTW:SKHZ:3WFW:KNMJ
Debug mode (server): true
Debug mode (client): false
Fds: 36
Goroutines: 55
EventsListeners: 1
Init Path: /usr/local/bin/docker
Docker Root Dir: /mnt/sda1/var/lib/docker

Same here, although not through boot2docker but on Ubuntu 14.04 directly.  These containers are frequently not removed. They are created using a bash script that creates a container from within the consul container by having the docker.sock mounted. It's using docker run --rm --net container:$container_id ..... as well.
% docker info
Containers: 3596
Images: 222
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 7423
Execution Driver: native-0.2
Kernel Version: 3.13.0-44-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 4
Total Memory: 15.67 GiB
Name: docker02
ID: EOVE:DWGJ:AE2W:YLT5:F27M:IEJL:Q33E:FQCJ:ASIN:EHCM:ACH4:WJND
Username: bvadevops
Registry: [https://index.docker.io/v1/]
WARNING: No swap limit support

% docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

@remmelt, these containers are not removed because Docker ignores --rm flag when there is a problem launching container. This is a weird, but expected behavior of Docker, so what you're seeing is in fact a docker-consul's issue.
See this comment in docker-consul's issue. I made a fork that resolves this and several other issues of docker-consul. Here is the related commit.

Thank you!

I also see this error sometimes when running the Flocker test suite.  For example:
[ERROR]
Traceback (most recent call last):
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/trial/util.py", line 296, in _runSequentially
    thing = yield d
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/python/threadpool.py", line 196, in _worker
    result = context.call(ctx, function, *args, **kwargs)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/python/context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/python/context.py", line 81, in callWithContext
    return func(*args,**kw)
  File "/home/exarkun/Projects/flocker/master/flocker/node/_docker.py", line 507, in _remove
    self._client.remove_container(container_name)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/docker/client.py", line 896, in remove_container
    self._raise_for_status(res)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/docker/client.py", line 94, in _raise_for_status
    raise errors.APIError(e, response, explanation=explanation)
docker.errors.APIError: 500 Server Error: Internal Server Error ("Cannot destroy container DockerClientTests-flocker-node-functional-test_docker-DockerClientTests-test_list_removed_containers-888568622283900587922261: Driver aufs failed to remove root filesystem 83692922f272e460b71efdecf129064d3279f5072c2c1e70afcb38c73798c2fa: rename /var/lib/docker/aufs/diff/83692922f272e460b71efdecf129064d3279f5072c2c1e70afcb38c73798c2fa /var/lib/docker/aufs/diff/83692922f272e460b71efdecf129064d3279f5072c2c1e70afcb38c73798c2fa-removing: device or resource busy")

flocker.node.functional.test_docker.DockerClientTests.test_list_removed_containers

and
[ERROR]
Traceback (most recent call last):
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/python/threadpool.py", line 196, in _worker
    result = context.call(ctx, function, *args, **kwargs)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/python/context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/twisted/python/context.py", line 81, in callWithContext
    return func(*args,**kw)
  File "/home/exarkun/Projects/flocker/master/flocker/node/_docker.py", line 507, in _remove
    self._client.remove_container(container_name)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/docker/client.py", line 896, in remove_container
    self._raise_for_status(res)
  File "/home/exarkun/Environments/flocker/local/lib/python2.7/site-packages/docker/client.py", line 94, in _raise_for_status
    raise errors.APIError(e, response, explanation=explanation)
docker.errors.APIError: 500 Server Error: Internal Server Error ("Cannot destroy container flocker--912891792647--622134077079: Driver aufs failed to remove root filesystem 005d96d8ce4ca2d74242cc3873772274dff60fb5980b2ce05413d18e9d0d9d70: rename /var/lib/docker/aufs/diff/005d96d8ce4ca2d74242cc3873772274dff60fb5980b2ce05413d18e9d0d9d70 /var/lib/docker/aufs/diff/005d96d8ce4ca2d74242cc3873772274dff60fb5980b2ce05413d18e9d0d9d70-removing: device or resource busy")

flocker.node.functional.test_docker.IDockerClientNamespacedTests.test_add_and_remove

These are both tests that use the Docker API to create and then quickly stop and remove a container.
$ sudo docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8
$ sudo docker info
Containers: 3
Images: 39
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 51
Execution Driver: native-0.2
Kernel Version: 3.13.0-44-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 8
Total Memory: 62.89 GiB
Name: preon
ID: REGQ:VSJY:T7LE:7RHM:GCW7:QHGZ:K2YJ:L72Z:KLP3:54DY:JO27:EM35
WARNING: No swap limit support

I’m also observing this, docker 1.4.1 on Linux 3.16.0-0.bpo.4-amd64.

And some numbers: Of 1820 created short-living containers, 240 caused this error.
This is particularly annoying as docker run will print this error message on stderr, confusing tools that use the output of that to determine whether the actual job was successful.

Upgraded to 1.5.0, same problem.

Simple repro case. Under zsh, run:
while true; do echo "exit" | docker run -i --rm busybox; if (( ${?} != 0 )); then break; fi; done
Run 2-3 parallel instances of the script, if desired.
  How long do you typically run this before you see a problem?
Here's my docker info:
Containers: 20
Images: 231
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 271
Execution Driver: native-0.2
Kernel Version: 3.13.0-44-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 8
Total Memory: 62.89 GiB
Name: ...
ID: ...
 I don't have the docker info/version handy at this time.
At work, I can repro this in at most 15-20 minutes with 2 scripts running concurrently (on the configuration described above). I'll try more concurrent scripts today.

I experience this problem in ubuntu-14.04 on a vmware host

+1

I encounter this issue as well with docker 1.4.1.  It happens on a busy machine within a processing pipeline:
Error response from daemon: Cannot destroy container eccd3089dc18912001f2047431810e14c4b1808b470bac063a39f87bee16d5be: Driver aufs failed to remove root filesystem eccd3089dc18912001f2047431810e14c4b1808b470bac063a39f87bee16d5be: rename /var/lib/docker/aufs/diff/eccd3089dc18912001f2047431810e14c4b1808b470bac063a39f87bee16d5be /var/lib/docker/aufs/diff/eccd3089dc18912001f2047431810e14c4b1808b470bac063a39f87bee16d5be-removing: device or resource busy

+1
I am seeing the same as well with docker 1.6.0. I dont really have anything complicated running on the machine, but the containers I am trying to remove seem to be dead, if that matters.
sysadmin@docker10:~$ tail -F /var/logs/docker.log
time="2015-04-17T12:25:31Z" level=info msg="DELETE /v1.18/containers/b49bb2f86b12"
time="2015-04-17T12:25:31Z" level=info msg="+job rm(b49bb2f86b12)"
Cannot destroy container b49bb2f86b12: Driver aufs failed to remove root filesystem b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb: rename /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb-removing: device or resource busy
time="2015-04-17T12:25:31Z" level=info msg="-job rm(b49bb2f86b12) = ERR (1)"
time="2015-04-17T12:25:31Z" level=error msg="Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container b49bb2f86b12: Driver aufs failed to remove root filesystem b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb: rename /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb-removing: device or resource busy"
time="2015-04-17T12:25:31Z" level=error msg="HTTP Error: statusCode=500 Cannot destroy container b49bb2f86b12: Driver aufs failed to remove root filesystem b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb: rename /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb-removing: device or resource busy"
Error response from daemon: Cannot destroy container b49bb2f86b12: Driver aufs failed to remove root filesystem b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb: rename /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb /var/lib/docker/aufs/diff/b49bb2f86b12163de792f9511fc4bffb49cb8b880a0a251e12591642ffb3b8eb-removing: device or resource busy
time="2015-04-17T12:25:31Z" level=info msg="DELETE /v1.18/containers/eac104ae9157"
time="2015-04-17T12:25:31Z" level=info msg="+job rm(eac104ae9157)"
Cannot destroy container eac104ae9157: Driver aufs failed to remove root filesystem eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8: rename /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8 /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8-removing: device or resource busy
time="2015-04-17T12:25:31Z" level=info msg="-job rm(eac104ae9157) = ERR (1)"
time="2015-04-17T12:25:31Z" level=error msg="Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container eac104ae9157: Driver aufs failed to remove root filesystem eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8: rename /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8 /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8-removing: device or resource busy"
time="2015-04-17T12:25:31Z" level=error msg="HTTP Error: statusCode=500 Cannot destroy container eac104ae9157: Driver aufs failed to remove root filesystem eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8: rename /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8 /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8-removing: device or resource busy"
Error response from daemon: Cannot destroy container eac104ae9157: Driver aufs failed to remove root filesystem eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8: rename /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8 /var/lib/docker/aufs/diff/eac104ae915764a2bd181fe818e0a6431d330c08f9c2369ddaede48b4b689eb8-removing: device or resource busy

sysadmin@docker10:~$ sudo docker version
Client version: 1.6.0
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 4749651
OS/Arch (client): linux/amd64
Server version: 1.6.0
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 4749651
OS/Arch (server): linux/amd64

sysadmin@docker10:~$ sudo docker info
Containers: 3
Images: 81
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 87
 Dirperm1 Supported: false
Execution Driver: native-0.2
Kernel Version: 3.10.48-3.10.6-amd64-13160847
Operating System: Ubuntu precise (12.04.2 LTS)
CPUs: 8
Total Memory: 15.68 GiB
Name: docker10
ID: CR2N:5JNE:S6XA:NNXS:FEQD:IVTM:7NCL:INCB:3AAS:CCKJ:XWUU:5FF2

CONTAINER ID        IMAGE                                                              COMMAND                CREATED             STATUS              PORTS                     NAMES
8aa56e3ba83f        gliderlabs/registrator:latest                                      "/bin/sh -c '/bin/re   About an hour ago   Up About an hour                              dope_container
b49bb2f86b12        hub.abc.com/application/test-img:latest                            "/bin/sh -c '/usr/lo   20 hours ago        Dead                <IP_ADDRESS>:31000->8080/tcp
eac104ae9157        gliderlabs/registrator:latest                                      "/bin/sh -c '/bin/re   20 hours ago        Dead

Albeit I'm on an older version of Ubuntu:
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 13.10
Release:	13.10
Codename:	saucy
My guess is that I'd see this in newer versions as well based on the thread here.
I observed this error today as well:
'''
13:05:17-ubuntu~$ sudo service docker stop
docker stop/waiting
13:06:26-ubuntu~$ sudo rm -rf /var/lib/docker
rm: cannot remove ‘/var/lib/docker/aufs’: Device or resource busy
13:06:29-ubuntu~$ ps aux | grep dockerubuntu    4313  0.0  0.0   9692   948 pts/9    S+   13:06   0:00 grep --color=auto docker
13:06:47-ubuntu~$
'''

I hit this on docker version: 1.6.0.
I was able to remove the container with docker rm -f

I originally reported this in Dec 2014 with docker 1.3.x. FWIW I've been using docker-compose and docker client&server 1.5 and 1.6 with boot2docker on osx and docker-machine, and have not seen the Cannot destroy container error.

I hit this on docker version: 1.6.0
the container cannot stop,just hang on it
and after restart docker service
it cannot remove

I saw this on docker 1.6.0 build 4749651 on Ubuntu 14.04.  I had some containers (not sure whether they were running on killed) on docker 1.5.0.  I upgraded to docker 1.6.0 and then immediately afterwards tried to remove the containers.
docker rm -f seemed to work

I spoke too soon, just saw this while doing a few simultaneous Dockerfile builds with docker 1.6.0 client on OSX against a digitalocean 1.6.1 server.
Error removing intermediate container a0568433a48a: Driver aufs failed to remove root filesystem a0568433a4...: rename /var/lib/docker/aufs/diff/a0568433a48a... /var/lib/docker/aufs/diff/a0568433a4...-removing: device or resource busy

rm -f it isn't the solution, it just remove the container entry from ps -a, volume still remain there, eating up precious disk space.

@gionn What about rm -vf?

@billsmith docker rm -f -v name doesn't work too, when the server under "heavy" load. we run all our tests with docker and when too much tests run in parallel the remove of the container fails with this error.

in case any swarm users encounter this..
I hit a variant of this with swarm just now. I restarted the 'swarm join' container on a CoreOS node that was having some health issues, which I suspect triggered a few container restart policies all at once.
$ docker rm -f $id
Error response from daemon: 500 Internal Server Error: Cannot destroy container $id: Driver overlay failed to remove root filesystem $id: remove /var/lib/docker/overlay/$id/merged: device or resource busy FATA[0001] Error: failed to remove one or more containers
I waited 5 minutes, ran the same rm -f $id, and it said 'no such container'.

Also seeing this under Debian wheezy when running a docker-running container inside Kubernetes.  docker rm -f seems to remove the container.

+1, http://stackoverflow.com/questions/30550472/docker-container-with-status-dead-after-consul-healthcheck-runs
no solution yet?

In the meantime I've setup a stinky workaround for this bug in the chef recipe we use to deploy containers.
These are the findings:

it always happens on certain containers, hence I wasn't able to track down a specific characteristics e.g. volume, ports, etc (even a stupid ubuntu or centos running a sleep 9999 will trigger this, but not on a clean system, it just start to happen after a while)
the dead container can be removed successfully (with docker rm without -f flag) after a new version of the same image is run (leading to a new dead container, but the old can now be removed)

+1 I hit this all the time, it is not consistent with any specific dockerfile
Error removing intermediate container 9b63e9a1e9bf: Driver aufs failed to remove root filesystem 9b63e9a1e9bf1aaa97d943b4c082eaa152e38d55bf1884bc28d88de1cc891f1a: rename /docker/aufs/mnt/9b63e9a1e9bf1aaa97d943b4c082eaa152e38d55bf1884bc28d88de1cc891f1a /docker/aufs/mnt/9b63e9a1e9bf1aaa97d943b4c082eaa152e38d55bf1884bc28d88de1cc891f1a-removing: device or resource busy

info
root@zapdos:/home/zapdos# docker -D version && docker -D info
Client version: 1.6.0
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 4749651
OS/Arch (client): linux/amd64
Server version: 1.6.0
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 4749651
OS/Arch (server): linux/amd64
Containers: 650
Images: 8317
Storage Driver: aufs
 Root Dir: /docker/aufs
 Backing Filesystem: extfs
 Dirs: 9626
 Dirperm1 Supported: false
Execution Driver: native-0.2
Kernel Version: 3.13.0-29-generic
Operating System: Ubuntu 14.04 LTS
CPUs: 32
Total Memory: 58.81 GiB
Name: zapdos
ID: HHHH:IIII:MRNF:OYNJ:FZNT:X4EA:ZWQR:TF7G:EEEE:HSP6:RYBS:F3ER
Debug mode (server): false
Debug mode (client): true
Fds: 1111
Goroutines: 3753
System Time: Wed Jul 15 18:54:22 UTC 2015
EventsListeners: 1
Init SHA1:<PHONE_NUMBER>1dbf64c1111c27861111027c
Init Path: /usr/bin/docker
Docker Root Dir: /docker
WARNING: No swap limit support

@anandkumarpatel and I are seeing this very frequently with weave attach containers

Seeing the same on a number of containers, on various ports, with and without volumes mounted. All are linked to at least one other running container.  It was started with this command:
docker run -d \
           -p 8500:8500 \
           -p 8300-8302:8300-8302/tcp \
           -p 8300-8302:8300-8302/udp \
           -h consul progrium/consul -server -bootstrap

I tried to remove it with:
$ docker rm -f<PHONE_NUMBER>cf

And:
$ docker stop<PHONE_NUMBER>cf && docker rm -f<PHONE_NUMBER>cf

And:
$ docker kill<PHONE_NUMBER>cf && docker rm -f<PHONE_NUMBER>cf

But got the same issue:
Error response from daemon: Cannot destroy container<PHONE_NUMBER>cf: Driver aufs failed to remove root filesystem<PHONE_NUMBER>cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076: rename /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076 /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076-removing: device or resource busy
Error: failed to remove containers: [5515181938cf]

Then I restarted the docker service:
$ service docker restart

After that the container was in the Exited state:
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                       PORTS                                                                                NAMES
5515181938cf        progrium/consul     "/bin/start -server -"   About an hour ago   Exited (137) 8 seconds ago   53/tcp, <IP_ADDRESS>:8300-8302->8300-8302/tcp, 8400/tcp, 53/udp, <IP_ADDRESS>:8500->8500/tcp, <IP_ADDRESS>:8300-8302->8300-8302/udp   elegant_fermat

But I still couldn't remove it:
$ docker rm<PHONE_NUMBER>cf
Error response from daemon: Cannot destroy container<PHONE_NUMBER>cf: Driver aufs failed to remove root filesystem<PHONE_NUMBER>cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076: rename /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076 /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076-removing: device or resource busy
Error: failed to remove containers: [5515181938cf]

Here is the content of this directory:
$ ls -al /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076
total 20
drwxr-xr-x  5 root root 4096 Jul 29 09:14 .
drwxr-xr-x 22 root root 4096 Jul 29 09:14 ..
drwxr-xr-x  2 root root 4096 Jul 29 09:14 data
-r--r--r--  1 root root    0 Jul 29 09:14 .wh..wh.aufs
drwx------  2 root root 4096 Jul 29 09:14 .wh..wh.orph
drwx------  2 root root 4096 Jul 29 09:14 .wh..wh.plnk

lsof returned nothing:
$ lsof +D /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076

I also couldn't remove it manually:
$ rm -rf /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076
rm: cannot remove ‘/var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076’: Device or resource busy

Then I found out that the consul process was still running:
$ pa aux | grep consul
root     30879  0.1  2.0 33960432 10160 ?      Ssl  09:14   0:09 /bin/consul agent -config-dir=/config -server -bootstrap

After killing the process manually I could remove the directory and the container
$ service docker stop
$ kill 30879
$ rm -rf /var/lib/docker/aufs/diff/5515181938cf937a979ffd8feefe3cb1e44793840bb59f87be48cf980c9a3076
$ service docker start
docker start/running, process 31775
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                                                NAMES
5515181938cf        progrium/consul     "/bin/start -server -"   About an hour ago   Dead                53/tcp, <IP_ADDRESS>:8300-8302->8300-8302/tcp, <IP_ADDRESS>:8500->8500/tcp, <IP_ADDRESS>:8300-8302->8300-8302/udp, 53/udp, 8400/tcp   nostalgic_darwin
$ docker rm -f<PHONE_NUMBER>cf
5515181938cf
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

Also seeing this with docker 1.6.0 (not the first time I've seen it).

+1

It seems that this bug is filling up out filesystems when the container is started and destroyed frequently.
Client:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:35:49 UTC 2015
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:35:49 UTC 2015
 OS/Arch:      linux/amd64

Is there a recommended filesystem where this doesn't happen? I've seen it so far on both aufs and btrfs.

@ErikGrimes users reporting that using overlayfs solves such problems:
http://blog.cloud66.com/docker-with-overlayfs-first-impression/

Ok.  How do you migrate existing container data to the new filesystem?

We were foresighted and we only used host directories for volumes. :+1:

I've got the same issue on the docker 1.6.2. I've stopped the docker and have uninstalled it. Then I've tried to remove /var/lib/docker directory and I've found many (about 100) process which block this directory (inner directories). I think those processes were inside stopped containers.  I've stopped all of them, but only reboot unlocked finally the directory.

Has anybody read  http://blog.hashbangbash.com/2014/11/docker-devicemapper-fix-for-device-or-resource-busy-ebusy/?   That blog says the issue is about mount name space.
I followed the instructions and avoid "aufs error" by modifing  /etc/init/docker.conf.
Replace
exec "$DOCKER" -d $DOCKER_OPTS
with
exec /bin/sh -c "unshare -m $DOCKER – -d $DOCKER_OPTS".
If  "aufs ...resouce busy error"  has happened already,   I usually restart the computer.  After restarting,  "docker rm "  can remove the container successfully.

@mimiyan Unfortunately this is a bit of a hack and breaks certain things.
For instance, if you start docker via unshare -m and then subsequently mount a new filesystem on the host, then try to docker run -v /path/to/new/fs:/foo, it will fail since Docker won't see that mount.
I've also seen AUFS run really well and then on another machine just not work at all (for instance, on two identical DO machines).
I think it's more likely that there is a race condition somewhere that can be triggered a lot under certain circumstances, because I've seen this on a fresh Ubuntu install with nothing but Docker... and for that matter I've seen it with boot2docker, and I know nothing else was sharing these mounts.
Docker does have a bit of a work-around in dealing this case. Namely that if there is an issue removing a container, the container will have a new state called "Dead", in which case you can try to remove it again, or investigate why resource was busy and manually resolve.

Oh, nice, that' why "Dead" shows up, which i was wondering recently.
I believe this should be nice doc(ed), if it has not been, 'cause it's somewhat confusing.

cpuguy83 made a good point of the disadvantage of  mounting docker daemon into its private name space.  But I would rather restart docker daemon after mounting a new file system than restarting the box in order to remove those Dead containers.
I also observed I rarely saw  Dead containers when  we used net bridge.   But after the net was changed from bridge to host,  there are more dead containers.   I guess the race condition is coming from network system.

@mimiyan I can somehow confirm this, it will explain why I am plenty of this errors on production (where we use --net=host, and NEVER happened con dev workstations).

I just want to report that I see the reported issue when I run google/cadvisor on Docker 1.8.1 like recommended in the cAdvisor README.
$ docker run --name issue9665 -d nginx
fe92aca8636c2756211f250517c0f792e4771725c42345701dcc917587e8016
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS               NAMES
fe92aca8636c        nginx               "nginx -g 'daemon off"   About a minute ago   Up About a minute   80/tcp, 443/tcp     issue9665
$ $ docker run \
>   --volume=/:/rootfs:ro \
>   --volume=/var/run:/var/run:rw \
>   --volume=/sys:/sys:ro \
>   --volume=/var/lib/docker/:/var/lib/docker:ro \
>   --publish=8080:8080 \
>   --detach=true \
>   --name=cadvisor \
>   google/cadvisor:latest
4c9ae9a61eabfeb0cacbe6e41351aab2ef2779328e725bfbfde99d07108a5a02
$ docker stop issue9665
issue9665
$ docker ps -a
CONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS                     PORTS                    NAMES
4c9ae9a61eab        google/cadvisor:latest   "/usr/bin/cadvisor"      32 seconds ago      Up 31 seconds              <IP_ADDRESS>:8080->8080/tcp   cadvisor
fe92aca8636c        nginx                    "nginx -g 'daemon off"   2 minutes ago       Exited (0) 6 seconds ago                            issue9665
$ docker rm issue9665
Error response from daemon: Cannot destroy container issue9665: Driver aufs failed to remove root filesystem fe92aca8636c2756211f250517c0f792e4771725c42345701dcc917587e80162: rename /var/lib/docker/aufs/mnt/fe92aca8636c2756211f250517c0f792e4771725c42345701dcc917587e80162 /var/lib/docker/aufs/mnt/fe92aca8636c2756211f250517c0f792e4771725c42345701dcc917587e80162-removing: device or resource busy
Error: failed to remove containers: [issue9665]
$ docker ps -a
CONTAINER ID        IMAGE                    COMMAND                  CREATED              STATUS              PORTS                    NAMES
4c9ae9a61eab        google/cadvisor:latest   "/usr/bin/cadvisor"      About a minute ago   Up About a minute   <IP_ADDRESS>:8080->8080/tcp   cadvisor
fe92aca8636c        nginx                    "nginx -g 'daemon off"   2 minutes ago        Dead
$ docker stop cadvisor
cadvisor
$ docker ps -a
CONTAINER ID        IMAGE                    COMMAND                  CREATED              STATUS                     PORTS               NAMES
4c9ae9a61eab        google/cadvisor:latest   "/usr/bin/cadvisor"      About a minute ago   Exited (0) 3 seconds ago                       cadvisor
fe92aca8636c        nginx                    "nginx -g 'daemon off"   3 minutes ago        Dead
$ docker rm fe92aca8636c
fe92aca8636c

Please notice that the issue9665 container looses its name in the attempt to remove it.

@rmetzler This is likely from mounting in /var/lib/docker into the container.

@cpuguy83 @rhvgoyal would implementing "deferred deletion", as was just done for device mapper (  https://github.com/docker/docker/issues/16380 https://github.com/docker/docker/pull/16381) be a solution for this one as well?

Seeing it again, on Ubuntu 14.04 and "Docker version 1.9.0-rc3, build 2100b94". At least I think it's same issue.
Step 9 : RUN mkdir -p /var/run/sshd ; chmod -rx /var/run/sshd
 ---> Using cache
 ---> 833356a6debd
Step 10 : ENV JAVA_CACERTS /usr/lib/jvm/java-openjdk/jre/lib/security/cacerts
Loaded plugins: fastestmirror
 ---> 5da44cb19fda
Error removing intermediate container 7c1617999505: rmdriverfs: Driver aufs failed to remove root filesystem 7c1617999505be6ad48eb2e44942480ba7f23a8cddc6a83fc20f797a5d411b30: rename /var/lib/docker/aufs/mnt/7c1617999505be6ad48eb2e44942480ba7f23a8cddc6a83fc20f797a5d411b30 /var/lib/docker/aufs/mnt/7c1617999505be6ad48eb2e44942480ba7f23a8cddc6a83fc20f797a5d411b30-removing: device or resource busy

I'm having the same issue. Please let me know if I can help with any debug logs. I upgraded from docker 1.7.1 to docker 1.9.0 on ubuntu 14:04
$ docker ps -a
2863fc832a61        flynn/slugrunner:latest   "/runner/init start a"   22 minutes ago      Dead                <IP_ADDRESS>:31404->5555/tcp

$ $ docker rm 2863fc832a61
Error response from daemon: Driver aufs failed to remove root filesystem 2863fc832a6149c3961e7e41e0039eaa6e1118666ec91034676a092d15faacd5: rename /var/lib/docker/aufs/mnt/2863fc832a6149c3961e7e41e0039eaa6e1118666ec91034676a092d15faacd5 /var/lib/docker/aufs/mnt/2863fc832a6149c3961e7e41e0039eaa6e1118666ec91034676a092d15faacd5-removing: device or resource busy
Error: failed to remove containers: [2863fc832a61]

Same issue Docker 1.9.0 on Debian 8 (jessie)
the container is mounting a /data/website dir on the host
user@host:~$ sudo docker ps -a | grep Dead
579f3527c931        nimmis/apache            "/my_init"               44 hours ago        Dead
user@host:~$ sudo docker rm 579f3527c931
Error response from daemon: Driver aufs failed to remove root filesystem 579f3527c931df3d540183ef802e7e5b14abf34ac08c122a519ef88a4bc83352: rename /var/lib/docker/aufs/mnt/579f3527c931df3d540183ef802e7e5b14abf34ac08c122a519ef88a4bc83352 /var/lib/docker/aufs/mnt/579f3527c931df3d540183ef802e7e5b14abf34ac08c122a519ef88a4bc83352-removing: device or resource busy
Error: failed to remove containers: [579f3527c931]
user@host:~$

Same issue here with 1.8 and Ubuntu 14.04.  I don't have any orphaned mounts showing in /proc/mounts and stopping all containers and the docker engine, and then starting the engine again doesn't help.  We are using volume mounts and --net host.

Hi guys, is it 100% reproducible or just every now and then? It would be great to have one of you to send us a reproducible case.

For me it was random when it was happening. There seemed to be a correlation to containers starting and exiting quickly, i.e. very short lived container instances that were started to run a quick command and exit and clean up.

For us it happens very regularly outside of any dev environment that sticks around for more than a few weeks.  I haven't been able to reproduce it at will, since most of our work happens in fairly short lived dev environments.

I don't understand the request for a repro case. I already provided one in https://github.com/docker/docker/issues/9665#issuecomment-89059499. Is there something wrong with that one?

@govidiupl I tried your repro scenario locally and with a few variations but couldn't reproduce the issue that we see in our long lived environments.  I'll try to leave it running for a few hours and see.  How long does it take you to reproduce it with that script?

A few seconds if I run 2 parallel instances.
~% while true; do echo "exit" | docker run -i --rm busybox; if (( ${?} != 0 )); then break; fi; done
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 3c88e811686b277b149a8a5cf03d2922c62de75f3e6d456f33246f35c4428f6d: rename /MOUNT_POINT_REDACTED/docker/aufs/mnt/3c88e811686b277b149a8a5cf03d2922c62de75f3e6d456f33246f35c4428f6d /MOUNT_POINT_REDACTED/docker/aufs/mnt/3c88e811686b277b149a8a5cf03d2922c62de75f3e6d456f33246f35c4428f6d-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 3a91bb1e66c2f06fe1c2c6517992046c596881a0e74cfd7e3a86543a2772590c: rename /MOUNT_POINT_REDACTED/docker/aufs/mnt/3a91bb1e66c2f06fe1c2c6517992046c596881a0e74cfd7e3a86543a2772590c /MOUNT_POINT_REDACTED/docker/aufs/mnt/3a91bb1e66c2f06fe1c2c6517992046c596881a0e74cfd7e3a86543a2772590c-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 57476fd74d193c269c43dc3cc76a1d7f1a6908ebb351cd230df3b56d908b6244: rename /MOUNT_POINT_REDACTED/docker/aufs/mnt/57476fd74d193c269c43dc3cc76a1d7f1a6908ebb351cd230df3b56d908b6244 /MOUNT_POINT_REDACTED/docker/aufs/mnt/57476fd74d193c269c43dc3cc76a1d7f1a6908ebb351cd230df3b56d908b6244-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem b77a5a75fcc81e2fc0749425c2573f644e111996fbf91f6ed8d8feee3e572975: rename /MOUNT_POINT_REDACTED/docker/aufs/mnt/b77a5a75fcc81e2fc0749425c2573f644e111996fbf91f6ed8d8feee3e572975 /MOUNT_POINT_REDACTED/docker/aufs/mnt/b77a5a75fcc81e2fc0749425c2573f644e111996fbf91f6ed8d8feee3e572975-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 2b5e45eb5fa8c965ce019154fd3cbb3e5e521d24ebfaba32bfa36f462001c40b: rename /MOUNT_POINT_REDACTED/docker/aufs/mnt/2b5e45eb5fa8c965ce019154fd3cbb3e5e521d24ebfaba32bfa36f462001c40b /MOUNT_POINT_REDACTED/docker/aufs/mnt/2b5e45eb5fa8c965ce019154fd3cbb3e5e521d24ebfaba32bfa36f462001c40b-removing: device or resource busy
^C%
~% docker info                                                 % 15-11-06 12:04
Containers: 15
Images: 13
Server Version: 1.9.0
Storage Driver: aufs
Root Dir: /MOUNT_POINT_REDACTED/docker/aufs
Backing Filesystem: extfs
Dirs: 43
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-66-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: REDACTED
ID: REDACTED
WARNING: No swap limit support
~% docker version                                              % 15-11-06 12:05
Client:
Version:      1.9.0
API version:  1.21
Go version:   go1.4.2
Git commit:   76d6bc9
Built:        Tue Nov  3 17:43:42 UTC 2015
OS/Arch:      linux/amd64
Server:
Version:      1.9.0
API version:  1.21
Go version:   go1.4.2
Git commit:   76d6bc9
Built:        Tue Nov  3 17:43:42 UTC 2015
OS/Arch:      linux/amd64
~%                                                             % 15-11-06 12:05

I easily reproduce this with govidiupl's script. I create a GCE VM with a standard 10GB persistent disk, and SSH in. After installing docker I ran:
for I in {1..5}; do (while true; do echo "exit" | docker run -i --rm busybox; if (( ${?} != 0 )); then break; fi; done) &> "$I" & done

Pretty much instantly I get errors:

Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 0aab68d4a3467c6cbd9cb1e77863f06553ce25b70ac8ae70038a4023fa39870d: rename /var/lib/docker/aufs/mnt/0aab68d4a3467c6cbd9cb1e77863f06553ce25b70ac8ae70038a4023fa39870d /var/lib/docker/aufs/mnt/0aab68d4a3467c6cbd9cb1e77863f06553ce25b70ac8ae70038a4023fa39870d-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 039c62aeba41944943d20d2945aa102f06565071596420791b49eb7817fcea23: rename /var/lib/docker/aufs/mnt/039c62aeba41944943d20d2945aa102f06565071596420791b49eb7817fcea23 /var/lib/docker/aufs/mnt/039c62aeba41944943d20d2945aa102f06565071596420791b49eb7817fcea23-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 2cc
b32e3e4b3405131c33b368f3c7d348da400f453b71a6d7bfc0264c85f896e: rename /var/lib/docker/aufs/mnt/2ccb32e3e4b3405131c33b368f3c7d348da400f453b71a6d7bfc0264c85f896e /var/lib/docker/aufs/mnt/2ccb32e3e4b3405131c33b368f3c7d348da400f453b71a6d7bfc0264c85f896e-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 09e9a9317eb1972b011c781110c05b1ca48dbc7194d8577a89ea526d43dcd356: rename /var/lib/docker/aufs/mnt/09e9a9317eb1972b011c781110c05b1ca48dbc7194d8577a89ea526d43dcd356 /var/lib/docker/aufs/mnt/09e9a9317eb1972b011c781110c05b1ca48dbc7194d8577a89ea526d43dcd356-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 32bc8921467ce411a2897d79138123448bd3929237a1cb479f30e379c6b5537c: rename /var/lib/docker/aufs/mnt/32bc8921467ce411a2897d79138123448bd3929237a1cb479f30e379c6b5537c /var/lib/docker/aufs/mnt/32bc8921467ce411a2897d79138123448bd3929237a1cb479f30e379c6b5537c-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 8a89ccb00559b93f3c9289fbdd6ce40ffc7edda52d6818717de6f6f971a1e049: rename /var/lib/docker/aufs/mnt/8a89ccb00559b93f3c9289fbdd6ce40ffc7edda52d6818717de6f6f971a1e049 /var/lib/docker/aufs/mnt/8a89ccb00559b93f3c9289fbdd6ce40ffc7edda52d6818717de6f6f971a1e049-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem 2ee
89350c9d25f7b0a667d5889a9d8445f83abecaabeff2ff179d6a8d62c5b1a: rename /var/lib/docker/aufs/mnt/2ee8935
0c9d25f7b0a667d5889a9d8445f83abecaabeff2ff179d6a8d62c5b1a /var/lib/docker/aufs/mnt/2ee89350c9d25f7b0a6
67d5889a9d8445f83abecaabeff2ff179d6a8d62c5b1a-removing: device or resource busy
Error deleting container: Error response from daemon: Driver aufs failed to remove root filesystem ebe
9e8221c31ae1e37f2a5a04d79a43422c77a0d02f25f5d0b17f479592e7b0e: rename /var/lib/docker/aufs/mnt/ebe9e82
21c31ae1e37f2a5a04d79a43422c77a0d02f25f5d0b17f479592e7b0e /var/lib/docker/aufs/mnt/ebe9e8221c31ae1e37f
2a5a04d79a43422c77a0d02f25f5d0b17f479592e7b0e-removing: device or resource busy

Docker version:
Client:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:37:20 UTC 2015
 OS/Arch:      linux/amd64
Server:
 Version:      1.9.0
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   76d6bc9
 Built:        Tue Nov  3 17:37:20 UTC 2015
 OS/Arch:      linux/amd64

I am constantly getting this error using both 1.7.1 and 1.8.1 on preprod and prod systems (preprod = not long running due to dev cycle) (prod = very long running, sometimes weeks)
The containers are running  python celery and uwsgi, once they start to queue up they cannot be shut down correctly using docker stop -t 600 <- yep it tried that, no dice
I've tried setting the Docker stop -t out longer and longer and it doesn't seem to make a difference.
Is there any chance someone is working on this? It's been an issue for years now and doesn't seem to have any solutions that work.
It would be nice to have a section of the documentation that tells users that even though Docker is being used in production it is not yet stable with AUFS and hopefully gives some solutions to running docker in a more stable fashion.
 However, GitHub is not a support forum and not the best place for explaining how to switch  to a different driver. We now have a new section in the documentation explaining the various storage drivers and how to use them; http://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/

We were also noticing similar issue Driver aufs failed to remove root filesystem, but after upgrading kernel to  3.19.0-25-generic we don't see this error anymore.

@rmetzler 's explanation helped me out: Stop cadvisor; then docker rm ...

I got this error with kernel 3.19.0-39 too see https://github.com/docker/docker/issues/3968#issuecomment-165374403

Getting this error for Driver devicemapper.
webdev2:~ # docker version
Client:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.3
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   f4bf5c7
 Built:
 OS/Arch:      linux/amd64
webdev2:~ # docker ps -a
CONTAINER ID        IMAGE                       COMMAND             CREATED             STATUS              PORTS               NAMES
6efab667b88d        openshift/origin-pod:v1.1   "/pod"              7 days ago          Dead
webdev2:~ # docker rm 6ef
Error response from daemon: Cannot destroy container 6ef: Driver devicemapper failed to remove root filesystem 6efab667b88d8aa1ad4e4a89582f3d21a4f4f6fba2dc9df018eb711c34df1ed6: Device is Busy
Error: failed to remove containers: [6ef]

Same problem and solved it just with umount:
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
6563dd842a83        postgres:9.4        "/docker-entrypoint.s"   25 hours ago        Dead                                    tiny_franklin
ac749a08434d        postgres:9.4        "/docker-entrypoint.s"   25 hours ago        Dead                                    trusting_kirch

$ mount
...
none on /var/lib/docker/aufs/mnt/ac749a08434dd9508503c6bdd43dfb09726646a4a79593500d8f5c913cda3a71 type aufs (rw,relatime,si=66a2e49a9d580fd1,dio)
none on /var/lib/docker/aufs/mnt/6563dd842a838b42eac342d3aef4ba2f4a989dca8d9cd562725687e8e23a3d5c type aufs (rw,relatime,si=66a2e49e760e7fd1,dio)

$ sudo umount /var/lib/docker/aufs/mnt/ac749a08434dd9508503c6bdd43dfb09726646a4a79593500d8f5c913cda3a71
$ sudo umount /var/lib/docker/aufs/mnt/6563dd842a838b42eac342d3aef4ba2f4a989dca8d9cd562725687e8e23a3d5c

$ docker rm 6563
$ docker rm ac74
$ docker ps -a
(empty list)

@ruFog That misses the point. Of course "umount" solves the problem, if you wait long enough. The problem is that stopping a container does a "umount" internally, and that fails due to a race condition with some unknown thing that keeps file descriptors around for the device.
Sure, if you want a workaround, "until sudo umount ${MOUNT_POINT}; do sleep 5; done". But that's the problem to begin with, Docker (or possibly some lower-level culprit) should do that correctly by itself.

I'm seeing this error during a build stage in docker 1.9.1. It continued to function but demonstrated this error. full log
This machine would have been under relatively heavy load processing 4 parallel build + test processes in docker containers. Typical load average for these machines is ~2.
Here's the relevant console outputs.
17:06:42 Step 17 : ENV ROSDISTRO_INDEX_URL https://raw.githubusercontent.com/ros/rosdistro/master/index.yaml
17:06:42  ---> Running in 9e109f73e134
17:06:43  ---> 89f69407c123
17:06:43 Error removing intermediate container 9e109f73e134: rmdriverfs: Driver aufs failed to remove root filesystem 9e109f73e134805c928c70f9f393726d861a74f45d96e624230a954b5d44a67f: rename /var/lib/docker/aufs/mnt/9e109f73e134805c928c70f9f393726d861a74f45d96e624230a954b5d44a67f /var/lib/docker/aufs/mnt/9e109f73e134805c928c70f9f393726d861a74f45d96e624230a954b5d44a67f-removing: device or resource busy
17:06:43 Step 18 : RUN rosdep init

Docker version and docker info from the logs.
# BEGIN SECTION: docker version
17:04:47 + docker version
17:04:47 Client:
17:04:47  Version:      1.9.1
17:04:47  API version:  1.21
17:04:47  Go version:   go1.4.2
17:04:47  Git commit:   a34a1d5
17:04:47  Built:        Fri Nov 20 13:12:04 UTC 2015
17:04:47  OS/Arch:      linux/amd64
17:04:47
17:04:47 Server:
17:04:47  Version:      1.9.1
17:04:47  API version:  1.21
17:04:47  Go version:   go1.4.2
17:04:47  Git commit:   a34a1d5
17:04:47  Built:        Fri Nov 20 13:12:04 UTC 2015
17:04:47  OS/Arch:      linux/amd64
17:04:47 + echo # END SECTION
17:04:47 # END SECTION
17:04:47 + echo # BEGIN SECTION: docker info
17:04:47
3. docker info
Hide Details

# BEGIN SECTION: docker info
17:04:47 + docker info
17:04:51 Containers: 319
17:04:51 Images: 21908
17:04:51 Server Version: 1.9.1
17:04:51 Storage Driver: aufs
17:04:51  Root Dir: /var/lib/docker/aufs
17:04:51  Backing Filesystem: extfs
17:04:51  Dirs: 22924
17:04:51  Dirperm1 Supported: false
17:04:51 Execution Driver: native-0.2
17:04:51 Logging Driver: json-file
17:04:51 Kernel Version: 3.13.0-48-generic
17:04:51 Operating System: Ubuntu 14.04.2 LTS
17:04:51 CPUs: 4
17:04:51 Total Memory: 15.67 GiB
17:04:51 Name: ip-172-31-6-102
17:04:51 ID: F26F:MOG6:HDN5:LSVU:VHW7:TNNK:NBRA:JVQG:H3CH:ZDUD:PHMK:7YLU
17:04:51 WARNING: No swap limit support
17:04:51 + echo # END SECTION
17:04:51 # END SECTION
17:04:51 [Idoc__carl_estop__ubuntu_trusty_amd64] $ /bin/sh -xe /tmp/hudson8392598443058835758.sh
17:04:51 + echo # BEGIN SECTION: Check docker status

Unfortunately this instance has been rotated out before I was able to debug into these logs.
However searching through my logs I find 2016 instances of this error in about 25000 attempts.
A snippet can be seen here:
Jbin_uU64__sound_play__ubuntu_utopic_amd64__binary/builds/1/log:Error removing intermediate container e02bb533fc41: rmdriverfs: Driver aufs failed to remove root filesystem e02bb533fc418c3cc134d7f64791e335e023c8934aacb774d7cc39554bb57573: rename /var/lib/docker/aufs/mnt/e02bb533fc418c3cc134d7f64791e335e023c8934aacb774d7cc39554bb57573 /var/lib/docker/aufs/mnt/e02bb533fc418c3cc134d7f64791e335e023c8934aacb774d7cc39554bb57573-removing: device or resource busy
Jbin_uU64__ueye__ubuntu_utopic_amd64__binary/builds/1/log:Error removing intermediate container c44f099d1bff: rmdriverfs: Driver aufs failed to remove root filesystem c44f099d1bffc73efa7e51a5549f547d20575dde21ab0e38dc87bd05c9184e05: rename /var/lib/docker/aufs/diff/c44f099d1bffc73efa7e51a5549f547d20575dde21ab0e38dc87bd05c9184e05 /var/lib/docker/aufs/diff/c44f099d1bffc73efa7e51a5549f547d20575dde21ab0e38dc87bd05c9184e05-removing: device or resource busy
Jbin_uU32__marti_sensor_msgs__ubuntu_utopic_i386__binary/builds/1/log:Error removing intermediate container 6c9addccada3: rmdriverfs: Driver aufs failed to remove root filesystem 6c9addccada3d3613727b7563db43c3320b503f28a742116f5d4d0b289f01c22: rename /var/lib/docker/aufs/mnt/6c9addccada3d3613727b7563db43c3320b503f28a742116f5d4d0b289f01c22 /var/lib/docker/aufs/mnt/6c9addccada3d3613727b7563db43c3320b503f28a742116f5d4d0b289f01c22-removing: device or resource busy
Jbin_uU64__rosapi__ubuntu_utopic_amd64__binary/builds/1/log:Error removing intermediate container d48e636a6d04: rmdriverfs: Driver aufs failed to remove root filesystem d48e636a6d042428382e7a2456ba3a4c5031d06db18a0556a664b21fbbff2747: rename /var/lib/docker/aufs/mnt/d48e636a6d042428382e7a2456ba3a4c5031d06db18a0556a664b21fbbff2747 /var/lib/docker/aufs/mnt/d48e636a6d042428382e7a2456ba3a4c5031d06db18a0556a664b21fbbff2747-removing: device or resource busy
Jbin_uT64__collada_parser__ubuntu_trusty_amd64__binary/builds/1/log:Error removing intermediate container d30a9fa5935c: rmdriverfs: Driver aufs failed to remove root filesystem d30a9fa5935c862320dffc95fe2f4a0dfb98ed1417b70d180445c4e346e1743b: rename /var/lib/docker/aufs/mnt/d30a9fa5935c862320dffc95fe2f4a0dfb98ed1417b70d180445c4e346e1743b /var/lib/docker/aufs/mnt/d30a9fa5935c862320dffc95fe2f4a0dfb98ed1417b70d180445c4e346e1743b-removing: device or resource busy
Jsrc_uV__shape_msgs__ubuntu_vivid__source/builds/1/log:Error removing intermediate container 581391a82307: rmdriverfs: Driver aufs failed to remove root filesystem 581391a82307806d5ab3e5bb5c4ad22ad7364541bc24f5353fbf05d025c0fd59: rename /var/lib/docker/aufs/mnt/581391a82307806d5ab3e5bb5c4ad22ad7364541bc24f5353fbf05d025c0fd59 /var/lib/docker/aufs/mnt/581391a82307806d5ab3e5bb5c4ad22ad7364541bc24f5353fbf05d025c0fd59-removing: device or resource busy
Jbin_uU64__grid_map__ubuntu_utopic_amd64__binary/builds/2/log:Error removing intermediate container b383b64333a6: rmdriverfs: Driver aufs failed to remove root filesystem b383b64333a6973088a25c3b3b40e50d8d92e6c1c3e6f126c3625e14d5240c7a: rename /var/lib/docker/aufs/mnt/b383b64333a6973088a25c3b3b40e50d8d92e6c1c3e6f126c3625e14d5240c7a /var/lib/docker/aufs/mnt/b383b64333a6973088a25c3b3b40e50d8d92e6c1c3e6f126c3625e14d5240c7a-removing: device or resource busy
Ibin_arm_uThf__mrp2_hardware__ubuntu_trusty_armhf__binary/builds/1/log:Error removing intermediate container 86bda4cf14aa: rmdriverfs: Driver aufs failed to remove root filesystem 86bda4cf14aa2a7c7bb3fe2999e61951c11df59522f31467d287277f8c8b874b: rename /var/lib/docker/aufs/diff/86bda4cf14aa2a7c7bb3fe2999e61951c11df59522f31467d287277f8c8b874b /var/lib/docker/aufs/diff/86bda4cf14aa2a7c7bb3fe2999e61951c11df59522f31467d287277f8c8b874b-removing: device or resource busy
Ibin_uT32__mrp2_simulator__ubuntu_trusty_i386__binary/builds/1/log:Error removing intermediate container 9457f5cd49f7: rmdriverfs: Driver aufs failed to remove root filesystem 9457f5cd49f71d10a7ce6322f148d76e753a612205534c41c65d027264cacb69: rename /var/lib/docker/aufs/diff/9457f5cd49f71d10a7ce6322f148d76e753a612205534c41c65d027264cacb69 /var/lib/docker/aufs/diff/9457f5cd49f71d10a7ce6322f148d76e753a612205534c41c65d027264cacb69-removing: device or resource busy
Isrc_uS__mrp2_viz__ubuntu_saucy__source/builds/1/log:Error removing intermediate container d9eb47796e49: rmdriverfs: Driver aufs failed to remove root filesystem d9eb47796e49f34e660ba5b31e629a701e419435fbe8a970c930421187818210: rename /var/lib/docker/aufs/mnt/d9eb47796e49f34e660ba5b31e629a701e419435fbe8a970c930421187818210 /var/lib/docker/aufs/mnt/d9eb47796e49f34e660ba5b31e629a701e419435fbe8a970c930421187818210-removing: device or resource busy

From the snippet it can be seen that the error occurs with a variety of dockerfiles. The line on which it fails is also quite diverse. Many are quick running commands like CMD ENV or echo but some are apt-get invocations which take much longer.
This was discovered in https://github.com/ros-infrastructure/ros_buildfarm/issues/134 and also might suggest reverting https://github.com/ros-infrastructure/buildfarm_deployment/pull/80

Also experience this problem on Debian 7. I also can reproduce it after reboot.
Docker version
`Client:
Version:      1.10.0
API version:  1.22
Go version:   go1.5.3
Git commit:   590d5108
Built:        Thu Feb  4 18:25:18 2016
OS/Arch:      linux/amd64
Server:
Version:      1.10.0
API version:  1.22
Go version:   go1.5.3
Git commit:   590d5108
Built:        Thu Feb  4 18:25:18 2016
OS/Arch:      linux/amd64`
Docker Info
Containers: 7  Running: 6  Paused: 0  Stopped: 1 Images: 193 Server Version: 1.10.0 Storage Driver: aufs  Root Dir: /var/lib/docker/aufs  Backing Filesystem: extfs  Dirs: 208  Dirperm1 Supported: true Execution Driver: native-0.2 Logging Driver: json-file Plugins:  Volume: local  Network: bridge null host Kernel Version: 3.16.0-0.bpo.4-amd64 Operating System: Debian GNU/Linux 7 (wheezy) OSType: linux Architecture: x86_64 CPUs: 8 Total Memory: 31.45 GiB Name: chell ID: BXX3:THMK:SWD4:FP35:JPVM:3MV4:XJ7S:DREY:O6XO:XYUV:RHXO:KUBS WARNING: No memory limit support WARNING: No swap limit support WARNING: No oom kill disable support WARNING: No cpu cfs quota support WARNING: No cpu cfs period support
uname -a
Linux chell 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3~bpo70+1 (2016-01-19) x86_64 GNU/Linux

Still seeing this issue on 1.10, but the error message is different now:
Failed to remove container (designate-api): Error response from daemon: Unable to remove filesystem for 4ad829a0e8a5bb45add135a7e1cfee323ffa378f9b9a3f09d36d939230137f1f: remove /var/lib/docker/containers/4ad829a0e8a5bb45add135a7e1cfee323ffa378f9b9a3f09d36d939230137f1f/mqueue: device or resource busy
Also, on 1.8.1 the container name would be changed.  now I have to rm -f the container to be able to reuse the container name.
docker info:
Containers: 10
 Running: 9
 Paused: 0
 Stopped: 1
Images: 3
Server Version: 1.10.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 54
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: son-file
Plugins:
 Volume: local
 Network: null host
Kernel Version: 3.13.0-67-generic
Operating System: Ubuntu 14.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.548 GiB
Name: dev02-control-001
ID: W27R:L56T:ZR74:VKCQ:RYT5:JSIT:PRJL:CT4A:N4UI:CBBU:2LGP:KUAZ
WARNING: No swap limit support

@mimiyan I reboot the computer according to your suggestion. It indeed resolved the "dead" container can not removed issue. Thanks!

Same as @dvorak with docker 1.10.2 and aufs storage.
Force removing the container did the trick for me (see line 2 of this systemd service extract)
ExecStartPre=-/usr/bin/docker stop registrator
ExecStartPre=-/usr/bin/docker rm -f registrator
ExecStartPre=/usr/bin/docker pull ${IMAGE_NAME}:${IMAGE_TAG}
ExecStart=/usr/bin/docker run --rm --name registrator \
-v /var/run/docker.sock:/tmp/docker.sock \
--net=host \
${IMAGE_NAME}:${IMAGE_TAG} \
${REGISTRY_URI}

Faced similar issue in deleting an old docker images directory ,
not in use by new docker-machine  installation.
$ sudo rm -rf  docker_images.old/
rm: cannot remove ‘docker_images.old/aufs’: Device or resource busy

Solved by  :
$ sudo service docker stop
$ sudo modprobe -r aufs
$ sudo rm -rf  docker_images.old/

Found a workarround for the problem, at least when used with docker-compose see https://github.com/docker/docker/issues/3786

i had run into this issue as well. removing the /:/rootfs:ro volume works around the issue for me.

Run into this device or resource busy error on ansible managed containers (on a re-create task), leaving containers Dead.
ansible/API log
Error removing container cc59a6ac0f600b4e98d6968a5c1c8d2b1277e95d0340a7400277920c0f28a570: 500 Server Error: Internal Server Error (\"{\"message\":\"Driver aufs failed to remove root filesystem cc59a6ac0f600b4e98d6968a5c1c8d2b1277e95d0340a7400277920c0f28a570: rename /docker/951968.951968/aufs/mnt/2a47f9db4760ad1880d862ab9d478703ce47e1a34109a042a0efc44dbb2d0357 /docker/951968.951968/aufs/mnt/2a47f9db4760ad1880d862ab9d478703ce47e1a34109a042a0efc44dbb2d0357-removing: device or resource busy"

journalctl docker log (same error)
level=error msg="Handler for DELETE /v1.24/containers/cc59a6ac0f600b4e98d6968a5c1c8d2b1277e95d0340a7400277920c0f28a570 returned error: Driver aufs failed to remove root filesystem cc59a6ac0f600b4e98d6968a5c1c8d2b1277e95d0340a7400277920c0f28a570: rename /docker/951968.951968/aufs/mnt/2a47f9db4760ad1880d862ab9d478703ce47e1a34109a042a0efc44dbb2d0357 /docker/951968.951968/aufs/mnt/2a47f9db4760ad1880d862ab9d478703ce47e1a34109a042a0efc44dbb2d0357-removing: device or resource busy"

using latest stable 1.12.4.
docker version
Client:
 Version:      1.12.4
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   1564f02
 Built:        Mon Dec 12 23:40:33 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.4
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   1564f02
 Built:        Mon Dec 12 23:40:33 2016
 OS/Arch:      linux/amd64

@ko-christ there are many reasons for that to happen, but basically it comes down to mounts leaking (running cAdvisor, which bind-mounts various directories, is a known cause for this). There is still an open issue tracking this, see https://github.com/docker/docker/issues/21704, which may contain useful information.
I'm locking this issue, because this issue is closed, and predates several issues that are still open.


Validate server trust asynchronously

Having the validation being done asynchronously will prevent blocking any thread associated with the network request.
The original synchronous methods have not been removed. If this commit/PR gets accepted I will come back and delete their implementations.
All applicable unit tests in AFSecurityPolicyTests have been duplicated to test the new asynchronous methods.

Can you rebase this with master to get Xcode 8 coverage?

Hi @kcharwood, the PR has been rebased with master.

Current coverage is 87.53% (diff: 95.60%)

Merging #3616 into master will increase coverage by 0.90%

@@             master      #3616   diff @@
==========================================
  Files            44         44
  Lines          6067       6668   +601
  Methods        1079       1164    +85
  Messages          0          0
  Branches        407        428    +21
==========================================
+ Hits           5256       5837   +581
- Misses          808        828    +20
  Partials          3          3

Powered by Codecov. Last update e337471...ef593af

Hi @kcharwood,
I'm just following up on this PR. Is there anything I can do to help the process of merging it?
I appreciate your work. Thank you.
Dalmo

Thanks for the PR! However, due to its age it will not be merged. If the issue is still occurring feel free to open a new PR.


Removed oidc client secret

Description
Changes proposed in this pull request:

No feature has been added, because of login issues, I had to remove the client secret.

Related issue(s)

/ok-to-test


PR for ekr-scripts2 branch

See #10. Something weird happened to my leojs repo. I cloned a new repo, closed the ekr-scripts branch, and created the ekr-script2 branch.

@boltex Félix, There is no rush to merge this branch. Do so only when convenient.
Feel free to email me with questions.


Update doc for CA1720 to stop mentioning obj

Fix #4995
This new feature is not yet publicly released. Please sync-up with @mavasani for when to merge this PR.

@Evangelink : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@mavasani @Evangelink @mikadumont Repo is locked today for Docs Build v3 updates. So, we  should be able to merge all the approved PRs on Friday, 4/17. Thanks!

#sign-off


how to change top bar background?

Hi! - love how the theme looks, but was interested in changing the background of the top bar to be the same one that's included with the Dark Trans Pride Theme  from the firefox theme store. would you happen to know how i could be able to find a way of extracting the background from that theme to replace in this one? and if so, would you tell me how to replace it in the userchome.css file?
changing the button colors might be simple enough but im not sure about the background, since it's probably an image file and not just a hex code.

Hey there NilTPL, I created a css background version of the flag which you can add to the element you want. I chose not to implement it myself as it looks ugly when put directly on the top bar, and you can definitely implement it in a way that actually works for you. Here's the css:
background: linear-gradient(120deg, #2b2a33 0%, #2b2a33 87.5%, #7ccbf4 87.5%, #7ccbf4 90%, #e9abb6 90%, #e9abb6 92.5%, #ffffff 92.5%, #ffffff 95%, #e9abb6 95%, #e9abb6 97.5%, #7ccbf4 97.5%, #7ccbf4 100%);

You can adapt the flag size by modifying the colours percentages (in pairs) and its angle by modifying the first value (120deg). You can also remove the black that pushes the flag to the right by removing the two instances of #2b2a33.
Good luck!


Training model on IAM Dataset

Hi,
According to your guide for training model on IAM Dataset, when I run "python main.py --train".
I receive the following error:
Traceback (most recent call last):
File "main.py", line 97, in
infer(fnInfer)
File "main.py", line 86, in infer
model = Model(open(fnCharList).read(), mustRestore=True)
File "E:\Users\Juzer\Dropbox\Master Thesis - Automatic Handling of Sheets\Implementation\SimpleHTR-master\SimpleHTR-master\src\Model.py", line 33, in init
(self.sess, self.saver) = self.setupTF()
File "E:\Users\Juzer\Dropbox\Master Thesis - Automatic Handling of Sheets\Implementation\SimpleHTR-master\SimpleHTR-master\src\Model.py", line 106, in setupTF
raise Exception('No saved model found in: ' + modelDir)
Exception: No saved model found in: ../model/
Can you help me?
Thanks in advance.

Yes, I did download the IAM Dataset for words and included it according to the instructions but I receive the mentioned error.

Hi, can you help me about what can be the issue?

I come back to you by the end of this week.

you have an old version of the repository but used the recent version of the README. The command line arguments changed since then.
The solution should be pretty simple: just get the newest version of this repository and you're done ;-)


Add changelog to the package, bug fix and change to PR template

Purpose

$Subject

Fixes: https://github.com/ballerina-platform/ballerina-standard-library/issues/1198

@lahirusamith, we don't need the issue template here in https://github.com/ballerina-platform/module-ballerina-sql/tree/master/.github

@BuddhiWathsala Fixed in e089f83


Fix crash when opening AboutActivity

Problem
The app crashes whenever the AboutActivity initializes. More info in #631.
Solution
The solution was to add the missing applicationComponent when building theDaggerAboutComponent.
Test(s) added
No tests were added/modified.
Screenshots
No UI modification.
Paired with
Nobody.

Thanks a lot @cmargonis !


 All options should include "how to cli" documentation.

Mostly a note to self--I'll tackle this eventually.

fixed, mostly.


win报错

应用程序无法正常启动（0xc00000tb)

Maybe check this out: https://ugetfix.com/ask/how-to-fix-error-code-0xc000007b-on-windows-10/
My guess is something wrong about the dependencies, e.g. VC Redist and/or .NET framework. If so, blame the software developer.
Again, not much I can help without more info. A screenshot will also be helpful.


Files aren't modified at all if they don't contain every single edit specification

For example, let's say I load 3 files in jmkvpropedit where the 1st and 2nd have 1 audio track and the 3rd file has 2 audio tracks. I then add new attachments to all files, change video title properties for all files, and change audio track number 2's title property then click Process files.
The first two will be left unprocessed (because it cannot find audio track number 2) while the 3rd will be properly processed. This results in losing the other attachment and video titles property edits I have done.
Instead jmkvpropedit should be able to do the edits that it can do (add the attachments and video title properties to the first two files as it is possible) and leave the edits it can't do out (like changing audio track number 2's title change in this case as it can't find a corresponding "a2")

Do not necessarily agreee with this. If it works the way you reques then you lose control of what is being modified and when. The way it curretly works allows you to only modify specific files that contain the changes you reuqire.
It is hardly difficult to uckeck the 'Edit this Track' option as you progress through your changes.


Adding limits on file uploads

Closes #471 by adding file upload limits:

[x] In the Uppy UI (100 GB in total and 10,000 files per upload)
[x] In the API:

[x] At the level of Flask MAX_CONTENT_SIZE -- now this value is configurable to prevent massive files filling /tmp disks that could lead to instability on some systems -- think we are unaffected on the current deployment but will try to verify later
[x] At the level of remaining disk space in the configured mount point, e.g., whether there is enough space in CONFIG.FILE_DIRECTORY to actually store the thing. This is done with a pymongo lock that prevents new files being uploaded until previous files have been correctly stored in the fs and database.

Also this PR makes the files directory on app startup, if not present. Previously the routes themselves were making it on first upload, potentially with all required subdirectories. This can be a bit dangerous if the files directory is a dynamic mount point, as the wrong disk may silently be used if not previously mounted. We should probably make this more robust in the future, with better specification of e.g. remote data sources too for the files directory (S3 or other blob storage). May be worth abstracting this away with something like Maggma as a "store" controller but equally this may overcomplicate things for little gain for us.
Additionally, in the future/now if easily done, it would be nice to add better feedback on failures in the UI, i.e., overriding the default uppy error message with better messages directly from our API. This might be straightforward to do but tricky to test.

Looks good to me, but I would set the max files and filesize much lower, at least for a demo folder. I can't think of a case we currently need to support 10,000 files uploaded at once-- and I imagine the server would not be happy.

Looks good to me, but I would set the max files and filesize much lower, at least for a demo folder. I can't think of a case we currently need to support 10,000 files uploaded at once-- and I imagine the server would not be happy.

If the 10,000 were tracked as one "file object" in the database then I think it would be fine -- doesn't seem unreasonable once we move to uploading folders of in situ data, or even bruker folders, but take your point for the demo server


Mixed usage of case class and class with serializable interface.

#203
This PR fixes mixed usage of case class and class with serializable interface.
It simply corrects some obvious cases at examples but did not for core, tools and data.
As I am not aware of coding conversion for PredictionIO, I would appreciate if you look through this closely.

Hello Hyukjin,
Thanks for contributing. There are two key changes in this PR: 1. Converting a case class Foo() extends Serializable into case class Foo().  2. Converting a class Foo() extends Serializable into a case class Foo().
Case 1 is good, since it is redundant to mixin Serializable into a case class.
But we have to be careful with the case 2, since scala forbids case-to-case inheritance, in other words, we cannot have another case class Bar() extends Foo(). In these examples, users may want to extends an existing TrainingData and create multiple subclass, each serving slightly different purpose. Because of the case-to-case restriction, even if we have base case class FOO(), all subclasses still need to be a non-case-class, which defies this PR's purpose of "fixing mixed usage of case class and class with serializable interface."

@yipjustin I see. Thanks! Let me remove those changes.

@yipjustin Thanks for comments. I just removed the changes.

LGTM


Fix missing icon alerts, attempt 2

We're still getting the missing icon alerts that should have been fixed by https://github.com/etchteam/recycling-locator/pull/195
The prop might be coming through as a string of "undefined", so trying this additional check.

:tada: This PR is included in version 1.49.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update leveldown dependency

The leveldown dependency is at ^0.10.2, meaning it will install 0.10.5. This causes node-gyp to blow up in Node 4.1.2. The latest leveldown is 1.4.2.
This is also causing the same problem in Superscript, too, unfortunately.
...
../node_modules/nan/nan.h:1514:12: note: in instantiation of function template specialization 'v8::Local<v8::Function>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(handle)->Get(kCallbackIndex)
           ^
../node_modules/nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
In file included from ../src/batch.cc:1:
In file included from /Users/me/.node-gyp/4.1.2/include/node/node.h:42:
/Users/me/.node-gyp/4.1.2/include/node/v8.h:221:5: error: assigning to 'v8::Object *volatile' from incompatible type 'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/me/.node-gyp/4.1.2/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:1632:12: note: in instantiation of function template specialization 'v8::Local<v8::Object>::Local<v8::Value>' requested here
    return NanEscapeScope(handle->Get(NanNew(key)).As<v8::Object>());
           ^
../node_modules/nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))
                             ^
9 errors generated.

...
npm ERR! Darwin 15.0.0
npm ERR! argv "/usr/local/Cellar/nvm/0.25.4/versions/node/v4.1.2/bin/node" "/usr/local/opt/nvm/versions/node/v4.1.2/bin/npm" "i" "sfacts" "--save"
npm ERR! node v4.1.2
npm ERR! npm  v2.14.4
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the leveldown package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls leveldown
npm ERR! There is likely additional logging output above.

Thanks John. I believe there are some PRs coming for node 5 support but yes, this is a problem still. I believe everything works fine up to node 0.12.x

Ah, too bad. We are only using 4.1.2. Looking forward to an update....

Closing this as leveldown will no longer used as of v1.0.0. Just as an aside, Travis now builds it happily on Node 0.12, 4, 5 and 6. Thanks for the heads up though @johnmenick.


crypto/x509/pkix/pkix: add missing RFC 5280 RDN OIDs

This PR modifies Go to comply to RFC 5280 with regard of human
readable representation of X.509 certificate distinguished names.
RFC 5280 section <IP_ADDRESS> states that conforming implementations
must/should expect a list of attribute types in Subject and
Issuer names. Some of the required attributes were not supported
by pkix.String(). This commit adds support for the missing RDN
attributes.
Updates #41750.

@googlebot I signed it!

This doesn't solve the issue.


The program failed to test my own data set

RuntimeError: upsample_nearest_nhwc only supports output tensors with less than INT_MAX elements

Have you reproduced it yet? Is it convenient to contact you?

Sorry, it didn't work out and I gave up
---- Replied Message ----
| From | @.> |
| Date | 05/05/2023 16:44 |
| To | @.> |
| Cc |<EMAIL_ADDRESS>|
| Subject | Re: [Lornatang/RFB_ESRGAN-PyTorch] The program failed to test my own data set (Issue #14) |
Have you reproduced it yet? Is it convenient to contact you?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Top gravity issue with viewPager inside the Panel

With gravity set as top, if I have a viewpager inside my Panel, the main content behind the panel will disappear while the panel is collapsing (sliding up) and then reappearing when the panelstate is collapsed.
This happens after the user swipes left/right between the pages of the panel.
If the gravity is set as bottom, everything works smoothly.
This look a bit similar with issue #450

Can you please provide a sample project that I can use to reproduce the issue?


Update third_party grpc-java and netty libraries [phab:D228]

Created by schroederc at 2015-05-05 22:51:36:

zarko accepted this revision at 2015-05-06 00:22:33

schroederc closed via commit e0527997d82fe4d5043735c093b1cc9c553b392a at 2015-05-06 15:31:58


Use transition JavaScript modules from Design System

This repo and the design system both have transition modules that are nearly identical. This PR removes the JS in this repo and points the codebase at the modules brought in through the design system.
https://github.com/cfpb/design-system/tree/main/packages/cfpb-atomic-component/src/utilities/transition
Changes

Use BaseTransition.js, MoveTransition.js, and AlphaTransition.js from design system and remove redundant modules and tests from this repo.

How to test this PR

Pull branch, run local server. Components that use move and alpha transitions should work as before. This is the mega menu, global search, blog filters, and feedback form, such as on http://localhost:8000/ask-cfpb/what-is-a-debt-to-income-ratio-why-is-the-43-debt-to-income-ratio-important-en-1791/

Transitions needs updating in DS

https://github.com/cfpb/design-system/pull/1134 needs to go in and be released first.


Request Injection

Can you add like this?

I get It, Next Ver Wiil support.

Thank you very much,i'll be wait for the new update <3

@AngleHony  By the way , did you include IRP unload button next version?


Create 2019 Prospectus

Just realized tonight that we don't have a 2019 prospectus to post on the website

@zachambrose is this item started yet?

I've made a first pass through the prospectus. @ChrisTheDBA , @jcwlib & @jhibbets Can you guys check out the questions I posted in comments? Thanks!

Added some comments in the document

I think we should be good to put the prospectus on the website. Thanks,
Janel!
On Wed, Mar 13, 2019 at 9:33 PM Janel<EMAIL_ADDRESS>wrote:

Added some comments in the document
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ncopenpass/NCOpenPass/issues/1418#issuecomment-472669685,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQ6Ixo6Y0WHFFHySD_OGFLtvmlmPUM0Bks5vWacGgaJpZM4akdec
.

--
Zach Ambrose
<EMAIL_ADDRESS>919-438-2752 (office)
919-616-9969 (cell)
www.AmbroseStrategy.com
https://www.linkedin.com/in/zambrose


make header image link to exaplanation instead of open image in new tab

I dont think anyone clicking the header image expects or wants to open the image in a new tab, it makes more sense to link them down to the explanation.

You can test this out here

Thanks for the PR, @purplepinapples !


Use tableHeight prop from react table as a fallback

Contributes to # (no issue yet, just spotted trying to use the infinite scroll hook)
There is a property from the react-table state called tableHeight which I set in my useDatagridState but gets overwritten by the useParentDimensions hook because tableHeight is also defined here but can be undefined
What did you change?
Simple one line change to fallback to the react-table prop if tableHeight in the useParentDimensions hook is undefined
How did you test and verify your work?
Only tested locally so far and works as expected for me

I have read the DCO document and I hereby sign the DCO.

recheck


Build failure

Attempting to build the process by your docs I get the following error:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.259 s
[INFO] Finished at: 2016-07-15T11:30:53-06:00
[INFO] Final Memory: 30M/271M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar (attach-javadocs) on project asynccassandra: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - /bin/sh: scl: line 1: syntax error: unexpected end of file
[ERROR] /bin/sh: error importing function definition for `BASH_FUNC_scl'

This happens when I just run mvn clean package in the root "asynccassandra" directory.

Removing the javadoc portion of the pom.xml lets the project build successfully.


IMetricsOutputFormatter implementations close stream being written to

I noticed that implementations of IMetricsOutputFormatter.WriteAsync close the stream that was passed to it. There are cases where this is undesirable; I might want to write multiple times to a stream when using the MetricsTextOutputFormatter, for example. Conceptually, I think it's very strange that the stream is automatically closed as a result of a write call.
The StreamWriter class is responsible for closing the stream in the above mentioned case, but its constructor has an overload to leave the stream open.
To have at least some degree of compatibility, a similar leaveOpen parameter could be added to the IMetricsOutputFormatter.WriteAsync method signature, with a default value of false. There would not be binary compatibility however, and custom implementations of the interface would need to be updated. I realize this is kind of high-impact for something that may seem like a minor thing, but perhaps you could consider this for the next major release.

Resolved in 3.2.0


Is it a safe software? who can tell me!!!!!!!!!!!!

Is it a safe software? who can tell me!!!!!!!!!!!!

it is safe. Now you dont have any reason why to believe me with that, but you can jump into the discord and have a chat with the people there. you can also take alook into the code (if you are have some programming skills) and check what it is doing.
But the biggest reason why to believe it is safe is that it is open-source and it is relatively high starred project on github.

This one is actually just a client for https://github.com/pinokiocomputer/pinokiod , so the actual code to look at is in that repository.
That repository has heaps of code and dependencies which can potentially execute arbitrary code, which is probably fine.
The obvious downside I can see it only has one contributor so far and does not really have community yet.


Update @actions/core to 1.10.0

Hello 👋
This PR update @actions/coreto version 1.10.0 in order to use the file version of save-state and set-output workflow commands.
It will remove this warning when using this github action:

Thank you 😄

👋 @SvanBoxel
Do you have some time to review this ?

Thanks for the ping! Reviewing now. @metzgegu

Thanks @SvanBoxel 😄
Could you release a new patch/minor version of this action ? or when do you plan to release a new version ?

👋 @SvanBoxel
Any plan for releasing a new version ? set-output command will be removed on 31st May 2023: GitHub changelog


rename OPENSPDM_ to LIBSPDM_ in config.h

Signed-off-by: Jiewen Yao<EMAIL_ADDRESS>

Looks good to me.


MIP0, MIP16, MIP24 Amendments - Core Unit Operating Model

DO NOT MERGE, this should be merged to master after acceptance.

RFC was merged with master and is being deleted.
Juan, please resubmit this PR to master :)


Regen APIs and add dfareporting:v2.7

Also bump version.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.

Coverage remained the same at 94.807% when pulling 46ea8b34a345d35a0fd2f8dd53c8ecfa092feacb on saicheems:regen into d7098fab9d194f50a0a16255c38343dad387521f on google:master.


WFLY-14327 Replace 'Java API for RESTful Web Services|JAX-RS, JavaSer…

Issue: https://issues.redhat.com/browse/WFLY-14327
(Replace "Java API for RESTful Web Services|JAX-RS, JavaServer Pages Standard Tag Library|JSTL, Java API for JSON Processing|JSON-P, Java API for XML-Based RPC|JAX-RPC" references in java doc with corresponding Jakarta EE ones)
Link with: https://github.com/wildfly/wildfly/pull/13808

CC- @asoldano @scottmarlow

CC- @asoldano @scottmarlow

Ok, I'll take a look.

Regarding the link to the Jakarta RESTful Web Services spec, it seems that there isn't a complete version online right now. A URL that can be used for now is: https://download.oracle.com/otndocs/jcp/jaxrs-2_1-final-eval-spec/index.html

I've added a few more changes.
Also, there are several uses of JAX-RS in org/jboss/as/jaxrs/LocalDescriptions.properties. I'm not sure if that matters.

I think it matters. @RanabirChakraborty , can you update the text there as well?

Finally, there are a number of uses of JAX-RS in the testsuite. Does that matter?

That is less relevant, though it would be nice dealing with it as well.

@ronsigal @asoldano Thanks for the review :) I have done the changes accordingly.


update command on v2.0.0-beta1 not working

Been testing the b1 build, only issue I found until now is that the update command doesn't work.
linux-and64 build.
Error: unknown command "update" for "qbt"
Run 'qbt --help' for usage.

That is because the beta1 does not have the update command, added it after tagging the release 😉 will tag a new one!


Small doc fixes found by the linkchecker

Signed-off-by: Sven Dowideit<EMAIL_ADDRESS>The documentation needs an index.md or alias for each output dir - idk enough about the content here, so I've given examples of each.
@moxiegirl

LGTM @SvenDowideit  thanks for the fix.


Add indexes.

Changes
Add 2 indexes "ix_polygon_labels_address_block_number" btree (address, block_number) and "ix_polygon_labels_address_block_timestamp" btree (address, block_timestamp)
Remove index ix_polygon_labels_address_label_label_data_type_and_name

How to test these changes?

Related issues

Created alembic table manually:
CREATE TABLE public.alembic_exploration_version (
    version_num character varying(32) NOT NULL
);

ALTER TABLE ONLY public.alembic_exploration_version
    ADD CONSTRAINT alembic_exploration_version_pkc PRIMARY KEY (version_num);

INSERT INTO public.alembic_exploration_version VALUES ('2fa541f6f6fc');


Semantic segmentation future merge master

I merged the current master and moved some of the files appropriately. I know there are a bunch of independent pull requests to merge the different functional components separately so this probably will never be permanently merged.
Nonetheless, this merge will probably let people use the fully convolutional networks while breaking things less until the fully reviewed merges in BVLC/caffe are done!

@ahundt thanks for the merge, but the FCN crop layer and coordinate mapping tools have been merged to master. See https://github.com/shelhamer/fcn.berkeleyvision.org for details on reference FCNs for the master branch.

@shelhamer fantastic! Thanks for setting up  https://github.com/shelhamer/fcn.berkeleyvision.org !


Made the CONTRIBUTING.md file better to read

Headings in bold and moved them to the center.
Points in bullets and added relevant emojis.
Preview:-

@markus-stoll what happened sir, why is it closed


Python Bolt display errors in modal window for wrong data entered by user

Hi,
I am working on an Slack app with Python Bolt framework and one of the things that app needs to do is to allow user to enter start and end date of an event. Everything works for me, except validation of entered data.
I want to check that the first date is before second date, both dates should be in the future and both dates should be selected, otherwise I would like to display an error message to the user.
Reproducible in:
@app.command("/add_event")
def handle_command(body, ack, respond, client, logger):
    ack()
    modal_view = {
        "type": "modal",
        "title": {"type": "plain_text", "text": "Select a Date"},
        "submit": {"type": "plain_text", "text": "Submit"},
        "close": {"type": "plain_text", "text": "Cancel"},
        "callback_id": "submit-modal",
        "blocks": [
            {
                "type": "section",
                "text": {"type": "mrkdwn", "text": "Select a date:"},
                "accessory": {
                    "type": "datepicker",
                    "initial_date": datetime.now().date().isoformat(),
                    "placeholder": {"type": "plain_text", "text": "Select a date"},
                    "action_id": "date",
                },
            }
        ],
    }
    client.views_open(
      trigger_id=body["trigger_id"],
      view=modal_view)

@app.action("submit-modal")
def handle_submission(ack, body):
    selected_date = body["view"]["state"]["values"]["date"]["datepicker"]["selected_date"]
    print(f"{selected_date}")
    if selected_date < datetime.now().date():
        response = {"response_action": "errors", "errors": {"date": "Please select a future date."}}
        ack(response)
    ack()

The slack_bolt version
slack-bolt==1.14.3
slack-sdk==3.18.3
Python runtime version
Python 3.8.10
OS info
~20.04.1-Ubuntu SMP Wed Jan 25 09:41:30 UTC 2023
Steps to reproduce:
Python code above
Expected result:
I expected a way to be able to show users that the data they entered was not correct if the dates are wrong / in the past
Actual result:
When I click submit on a modal it closes without any errors.
Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi @zkokelj! In your print statement, can you also include datetime.now().date()? What are both of those values when the comparison is hit?

In addition to Alissa's comment, let me suggest a few things:

"input" type blocks are the way to receieve view.state.values properly and displaying error messages for a "section" type block in a modal is not supported. Thus, please use an "input"  type block instead.
When migrating to an "input" type block, set its "block_id". The key "date" in "errors": {"date": "Please select a future date."} needs to be a block_id, not an action_id.
nit: for the pattern of ack() with errors, you can do early return to avoid the following unnecesary code execution.


How to query in a recursive way using QueryDSL+spring data jpa+gradle+mysql?

@Entity
public class Department {
	private Long id;
	private Long parentId;
}

I want to query all of children departments (include children's children and so on) by a department id in a recursive way with QueryDSL (using 5.0.0).
I know that it can be implemented using the withRecursive method of JPASQLQuery.
I read the Maven configuration in the official tutorial, but gradle doesn't know how to configure it, can you provide an example?
And provide an example of recursive query? thank you!
There is no @OneToMany or @ManyToOne, only parentId.
Related questions: #2150

implementation 'com.querydsl:querydsl-core:5.0.0'
implementation 'com.querydsl:querydsl-sql:5.0.0'
implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
annotationProcessor 'com.querydsl:querydsl-apt:5.0.0:jakarta'
annotationProcessor 'org.springframework.boot:spring-boot-starter-data-jpa'