Issue title: error creating overlay mount to /var/lib/docker/overlay2/<...>/merged: device or resource busy
 Issue body: <!--
This issue tracker is for *bug reports* and *feature requests*.
For questions, and getting help on using docker:

- Docker documentation - https://docs.docker.com
- Docker Forums - https://forums.docker.com
- Docker community Slack - https://dockercommunity.slack.com/ (register here: http://dockr.ly/community)
- Post a question on StackOverflow, using the Docker tag
-->

* [x] This is a bug report
* [ ] This is a feature request
* [x] I searched existing issues before opening this one

<!--
DO NOT report security issues publicly! If you suspect you discovered
a security issue, send your report privately to imoore@example.com.
-->

### Expected behavior
No errors

### Actual behavior
`error creating overlay mount to /var/lib/docker/overlay2/af8c5d19cde2039cf3b4c3b340b960bac2b2f0504b0b291f6c63c2d5175ea3ba/merged: device or resource busy`

dmesg:
`[55383.848708] overlayfs: lowerdir is in-use as upperdir/workdir`

( https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images/-/jobs/242656806 )

### Steps to reproduce the behavior

Install Fedora 30 and update the kernel to 5.1.15-300.fc30 (latest at time of creation of this issue)

Then as root:
```
git clone https://gitlab.com/freedesktop-sdk/infrastructure/freedesktop-sdk-docker-images.git
cd freedesktop-sdk-docker-images
docker build .
```
**Note:** kernels that do not have this [commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.1.y&id=99eb836cd9a4df455ae90807bc00ee635be342f0) do not suffer from the issue. It looks like this commit added more sanity checks around usage of overlayfs and **docker** is using overlayfs wrong. I could work around the issue by using an older kernel.

<!--
Describe the exact steps to reproduce. If possible, provide a *minimum*
reproduction example; take into account that others do not have access
to your private images, source code, and environment.

REMOVE SENSITIVE DATA BEFORE POSTING (replace those parts with "REDACTED")
-->

**Output of `docker version`:**

```
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-67.git1185cfd.fc30.ppc64le
 Go version:      go1.12.2
 Git commit:      1185cfd/1.13.1
 Built:           Mon Apr 22 17:47:08 2019
 OS/Arch:         linux/ppc64le

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-67.git1185cfd.fc30.ppc64le
 Go version:      go1.12.2
 Git commit:      1185cfd/1.13.1
 Built:           Mon Apr 22 17:47:08 2019
 OS/Arch:         linux/ppc64le
 Experimental:    false
```

**Output of `docker info`:**

```
Containers: 5
 Running: 1
 Paused: 0
 Stopped: 4
Images: 28
Server Version: 1.13.1
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: journald
Cgroup Driver: systemd
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Authorization: rhel-push-plugin
Swarm: inactive
Runtimes: oci runc
Default Runtime: oci
Init Binary: /usr/libexec/docker/docker-init-current
containerd version:  (expected: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1)
runc version: N/A (expected: 9df8b306d01f59d3a8029be411de015b7304dd8f)
init version: N/A (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  WARNING: You're not using the default seccomp profile
  Profile: /etc/docker/seccomp.json
 selinux
Kernel Version: 5.1.15-300.fc30.ppc64le
Operating System: Fedora 30 (Server Edition)
OSType: linux
Architecture: ppc64le
Number of Docker Hooks: 2
CPUs: 32
Total Memory: 31.93 GiB
Name: localhost.localdomain
ID: UU6X:5ECG:AJ3L:NBNZ:LUXT:XTMT:X4FK:NX7S:DLZN:EHEI:AEAX:FZJC
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 (364)524-1739
Live Restore Enabled: true
Registries: docker.io (secure), registry.fedoraproject.org (secure), quay.io (secure), registry.access.redhat.com (secure), registry.centos.org (secure), docker.io (secure)
```

**Additional environment details (AWS, VirtualBox, physical, etc.)**
QEMU/KVM

 Comments: 
 Comment 0: Simple patch against linux 5.2-rc7 to disable the check for a temporary workaround
https://gist.github.com/dougvj/e866760bb41b1d43aab79130ba1be1b3
 Comment 1: I'm getting around this by temporarily switching the `storage-driver` to `overlay` rather than the default `overlay2` ([see docs here](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-storage-driver)).
 Comment 2: I'm having the same issue but during push of an image to a private registry.
As @amrhassan suggests, temporarily changing the storage-driver to `overlay` works. But `overlay` is deprecated and will be removed so this issue should be fixed. 

Running on Arch Linux
`~/ uname -r
5.2.5-arch1-1-ARCH
`
Output of `sudo docker version`
`~/ sudo docker version
Client:
 Version:           19.03.1-ce
 API version:       1.40
 Go version:        go1.12.7
 Git commit:        74b1e89e8a
 Built:             Sat Jul 27 21:08:50 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          19.03.1-ce
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.7
  Git commit:       74b1e89e8a
  Built:            Sat Jul 27 21:08:28 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.7.m
  GitCommit:        85f6aa58b8a3170aec9824568f7a31832878b603.m
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
`

Output of `docker info`
`~/ sudo docker info 
Client:
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 19.03.1-ce
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 85f6aa58b8a3170aec9824568f7a31832878b603.m
 runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.2.5-arch1-1-ARCH
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.42GiB
 Name: nelo
 ID: A4RW:J5TK:QQC2:4T5M:JZXR:QBU6:B3VU:P7IJ:JTSK:DSFW:KDYN:M7WT
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  (364)524-1739
 Live Restore Enabled: false
`
 Comment 3: I experienced this issue when pushing to a private registry as well, and am working around it.
 Comment 4: We hit the same error on Amazon Linux 2 using the `kernel-ng` (_`sudo amazon-linux-extras install kernel-ng a`_)


`Linux sharedrunner 4.19.58-21.57.amzn2.x86_64 #1 SMP Thu Jul 11 07:59:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux`


 Comment 5: I'm using a private registry (built into GitLab) and have the same issue. The work-arounds listed above work for me. :)

```bash
sudo systemctl stop docker
sudo dockerd -s overlay
# Rebuild your image, and push.
```
 Comment 6: hm, but this fix will not survive a reboot.  
So the systemd unitfile must be patched

```diff
diff -ru home/ec2-user/docker.service /usr/lib/systemd/system/docker.service
--- home/ec2-user/docker.service	2019-08-02 08:44:04.910157580 +0200
+++ /usr/lib/systemd/system/docker.service	2019-08-02 08:44:(364)524-1739 +0200
@@ -14,7 +14,7 @@
 # the default is not to use systemd for cgroups because the delegate issues still
 # exists and systemd currently does not support the cgroup feature set required
 # for containers run by docker
-ExecStart=/usr/bin/dockerd $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_ADD_RUNTIMES
+ExecStart=/usr/bin/dockerd -s overlay $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_ADD_RUNTIMES
 ExecReload=/bin/kill -s HUP $MAINPID
 # Having non-zero Limit*s causes performance problems due to accounting overhead
 # in the kernel. We recommend using cgroups to do container-local accounting.

```

`sudo systemctl daemon-reload && sudo systemctrl restart docker`

I will observe it to see if it fixes the issue here as well.
 Comment 7: Can't that switch be passed through $OPTIONS? Where is it defined? 
 Comment 8: Sure. I guess it's `/etc/docker/daemon.json`  
See https://docs.docker.com/v17.09/engine/admin/systemd/

 Comment 9: > Sure. I guess it's `/etc/docker/daemon.json`

It is. This is what I'm using as a workaround:

```json
{
  "storage-driver": "overlay",
  "features": {"buildkit": true}
}
```

 Comment 10: I'm able to work around by setting only `storage-driver` in `/etc/docker/daemon.json`:

```json
{
  "storage-driver": "overlay"
}
```

As a word of warning, changing the storage driver will make all of your images/containers (volumes don't seem to be affected) dissappear. They're still there, but you have to switch back to `overlay2`.
 Comment 11: Let me note that the issue always happened while pushing images and never while building. I was mistaken with my test case in the first post. Updated.
 Comment 12: With buildkit enabled it happens when building larger images (> 1GB?) too.
 Comment 13: I've experienced this aswell when using GitLab-CI with docker-in-docker configuration,
using `--storage-driver=overlay` as suggested by https://github.com/docker/for-linux/issues/711#issuecomment-511450495 helps, thanks!
```
5.1.15-arch1-1-ARCH
Docker version 18.09.6-ce, build 481bc77156
```
```yml
dockerfiles:
  stage: pre-build
  script:
    - docker login -u "gitlab-ci-token" -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
    - docker pull $HEAD_IMAGE || docker pull $LATEST_IMAGE || true
    - docker build --tag $HEAD_IMAGE dockerfiles/
    - docker push $HEAD_IMAGE
```
```
docker push $HEAD_IMAGE
The push refers to repository [registry.xxxx/build]
fa2aa1697b3f: Preparing
efb57bb8d2cd: Pushing
..
fa2aa1697b3f: Retrying in 20 seconds
efb57bb8d2cd: Retrying in 20 seconds
..
efb57bb8d2cd: Pushing
error creating overlay mount to /var/lib/docker/overlay2/63db9c807e3f1db9cb8123f17874493d125d348d344d5870fdfb35b462adc6e3/merged: device or resource busy
```
 Comment 14: Downgrading docker version from
```
docker-1:19.03.1
```
to
```
docker-1:18.09.8
```
solved the problem in my case.
 Comment 15: I am getting this error with `Docker version 18.09.7, build 2d0083d` but it seems that I can get a successful build/push after 3-5 attempts. 
 Comment 16: To continue on the comment by @breimers: 

Because it successfully pushes 1-2 layers per attempt, the stability improved by setting 
```
--max-concurrent-uploads=1
```
on the docker daemon on the *pushing* side. If you have multiple clients this might be less-than-ideal, but when only the CI/CD pipeline pushes to docker, this might be a viable workaround. (Yes, it is slower this way.)

This way, no errors are thrown at all, and it won't have to wait in-between retries. 
 Comment 17: Same problem here. But only on one of two machine. Both machines are running arch linux with latest patches and use an m.2 ssd. Two main difference do had the pc's. PC 1 do not has an monitor connected. The assembled processors are
```bash
# uname -r
5.2.5-arch1-1-ARCH
```
PC 1: Intel(R) Celeron(R) CPU G3930 @ 2.90GHz
PC 2: AMD Ryzen 5 2600X Six-Core Processor

On **PC 1** The bug occurs heavly.
On **PC 2** The bug does not occurs.

 Comment 18: Alternatively, and until this issue is fixed, one can set the maximum number of parallel uploads to 1 to bypass the issue without changing to overlay.

Edit /etc/docker/daemon.json and set the max-concurrent-uploads variable.

```json
{
    "max-concurrent-uploads": 1
}
```
 Comment 19: Having this issues when pushing. Docker version 18.09.7-ce, build 2d0083d657
 Comment 20: me too , Manjaro docker version:19.03 .

i fix it 
```shell
sudo systemctl stop docker
sudo rm -rf /var/lib/docker
sudo vim /etc/docker/daemon.json
{
  "storage-driver": "overlay"
}
sudo systemctl start docker
```
it works.
 Comment 21: I am using docker version 1.13.1 and was facing the same issue. 
So I restart the docker and then pushed the image, and it worked fine for me. 

 Comment 22: while changing the storage driver from overlay2 to overlay fixes the issue, is this a good practice? especially as overlay cause excessive inode consumption (especially as the number of images grows)
 Comment 23: I also have this issue pushing to a private container registry (Azure Container Registry). Setting `max-concurrent-uploads` to 1 has worked around the problem successfully here as well.

On Fedora, there is no `daemon.json` by default, but `--max-concurrent-uploads=1` can be added to the `OPTIONS` in `/etc/sysconfig/docker`.
 Comment 24: Any body knows permanent fix for this..As we are also facing the same issue.but applying work around.  like including max-concurrent-uploads=1 . it worked fine. 
 Comment 25: I found that setting `max-concurrent-uploads=1` decreases frequency of the bug, but does not eliminate it completely, only after applying kernel patch I cannot spot it anymore
 Comment 26: Same problem here after a server upgrade to Debian 10 using kernel 4.19. I downgraded to Debian 9 using kernel 4.9. Now it works perfectly fine again. 
 Comment 27: Same problem on fedora 30 with kernel 5.2.14-200.fc30.x86_64
max-concurrent-uploads=1 works
 Comment 28: Same problem : overlay2 driver, latest docker:18-dind container image , host is on 5.3 kernel
 Comment 29: Same issue on armbian debian 10 on an asus tinker board (armhf)
 Comment 30: Not to pile on another +1 but I've been running into this while trying to build Kubernetes locally.

```
$ k8s.io/kubernetes make quick-release
...
...

 Comment 31: This should be fixed in the 2019-09 monthly update (19.03.3, 18.09.10), due next week.

If anyone wants to test a beta, it will appear in testing channel soon.
 Comment 32: @kolyshkin good news ! can we can a commit / PR link ? I'm curious about the fix provided.
 Comment 33: This appears to be the fix, https://github.com/moby/moby/pull/39780. 
 Comment 34: In my case, after restarting the Docker daemon the error disappeared. Running docker community edition on Ubuntu19.04. The new release sounds sweet!
 Comment 35: Restarting the Docker daemon also worked for me.
 Comment 36: Closing, as mentioned this should be fixed.
The patch will be in 19.03.3.

Thanks!
 Comment 37: $ docker version
Client: Docker Engine - Community
 Version:           19.03.3
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        a872fc2
 Built:             Tue Oct  8 01:11:58 2019
 OS/Arch:           linux/arm
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.3
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       a872fc2
  Built:            Tue Oct  8 01:05:59 2019
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

$ uname -a
Linux vertex007 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 9.11 (stretch)
Release:	9.11
Codename:	stretch

I have upgraded docker to 19.03.3 on my Raspbian/Raspberry Pi 3B+, the error is not gone.
 Comment 38: I can confirm that the error is still there on 19.03.3
 Comment 39: Jeep, still there with 5:19.03.3~3-0~debian-buster.
 Comment 40: My suspect is that I'm continuing to see the error because the build was using a cached layer built before the 19.03.3 upgrade.

I've now run `docker system prune -af` on all the hosts. If my suspicion is right, this should fix the issue.
 Comment 41: Docker version 18.09.6, build 481bc77156
Ubuntu 19.04

Can't `docker system prune -af` because docker daemon refuses to start. None of the suggested fixes work. 

How does one upgrade to 19.03.3? Newest version being shown is 18.09 (Already tried uninstalling / reinstalling)
 Comment 42: I can confirm this bug:
```
 hostnamectl
----skipped----
  Operating System: Ubuntu 18.04.3 LTS
            Kernel: Linux 5.0.0-31-generic
      Architecture: x86-64
```
```
docker version
Client: Docker Engine - Community
 Version:           19.03.4
 API version:       1.40
 Go version:        go1.12.10
 Git commit:        9013bf583a
 Built:             Fri Oct 18 15:54:09 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.4
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.10
  Git commit:       9013bf583a
  Built:            Fri Oct 18 15:52:40 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
```
@mdgomes solution working for me as workaround
 Comment 43: 19.03.4 here as well. We are getting hit by it in Kolla when doing image builds. No workaround applies.
 Comment 44: Hi.

Having the same issue, any updates?
 Comment 45: After upgrading the only time the issues has appeared for me was initially if a prune was not run because of cached layers, per the comment in https://github.com/docker/for-linux/issues/711#issuecomment-540490020.
 Comment 46: Debian 'buster' with default distro kernel + docker ce 19.03.4 fails:

```
INFO:kolla.common.utils.nova-base:Building started at 2019-11-01 09:51:16.368898
INFO:kolla.common.utils.nova-base:Directory /tmp/tmpfwvSiv/kolla-2019-11-01_09-46-01_kYr2TM/docker/nova/nova-base/additions already exist. Skipping.
INFO:kolla.common.utils.nova-base:Step 1/11 : FROM 116.69.203.115:4000/lokolla/debian-source-openstack-base:change_692520
INFO:kolla.common.utils.nova-base: ---> c3fdcca97957
INFO:kolla.common.utils.nova-base:Step 2/11 : LABEL maintainer="Kolla Project (https://launchpad.net/kolla)" name="nova-base" build-date="20191101"
ERROR:kolla.common.utils.nova-base:Error'd with the following message
ERROR:kolla.common.utils.nova-base:error creating overlay mount to /var/lib/docker/overlay2/9557e325e12034da6c072854e68b6c0c9cfc4fd33e5711305d5a007f06c989f8-init/merged: device or resource busy
```

It makes CI runs on Debian unusable ;(
 Comment 47: Yeah, this doesn't seem fully resolved from my perspective; I've got a k8s cluster here that was built with Docker version 19.03.4, build 9013bf583a (never had a previous version installed at all) presenting this error: on ubuntu 18.04 with Linux 4.15.0-66-generic.

Due to the fact that the docker version was always 19.03.4 running a `docker system prune -af` has no effect.
 Comment 48: $ vim /etc/docker/daemon.json
{
"max-concurrent-uploads": 1
}
$ service docker restart

Posting out this if this helps to someone. I had the same issue with the docker. It was not able to push images to GCR. The above will able to solved my issue.
 Comment 49: @AbhinayGupta741 nice to know. But the problem exists during building as well.
 Comment 50: hrw, I think Abhinay's comment might as well help us because we are building and pushing at the same time. We need to delay pushing too.
 Comment 51: > $ vim /etc/docker/daemon.json
> {
> "max-concurrent-uploads": 1
> }
> $ service docker restart
> 

This was mentioned repeatedly throughout this thread; not sure why there's a need to add it again... This is not a solution but rather a cheap work-around.

Question for the maintainers:
How can you say this is fixed if people are still reporting this issue _after_ a system prune?
 Comment 52: So, in the end, we did not need max-concurrent-uploads set to 1, but we needed to stop building and pushing at the same time:
kolla: https://review.opendev.org/694243
 Comment 53: Guys, this is still happening...

error creating overlay mount to /var/lib/docker/overlay2/e3003381a4b9d9ef5f527fb36eeb14b98709bedc5a5535f11c42011fae171cd2/merged: device or resource busy

```
$ docker -v
Docker version 19.03.5, build 633a0ea838
$ uname -r
4.19.0-6-amd64
```
 Comment 54: Oh yes, we have the same problem like @NoICE - when our Gitlab CI is building docker images, this problem occurs on daily basis. Using **deprecated** `overlay` instead of `overlay2` is the official solution? Really? Thanks!
 Comment 55: @NoICE @petr-fischer 
Try https://github.com/docker/for-linux/issues/711#issuecomment-540490020 and report back if it's still happening.

 Comment 56: I already tried to do docker system prune (without --all --force). But I'll try it again with them.

(Btw somewhere around these issue was mentioned that this should affect only linux >= 5.x, but I have this problem on 4.19.0. Don't know if this is the same core issue.)
 Comment 57: @choopm Unfortunately, still happening. Especially if parallel build of several (but different!) docker images is running (in the GitLab CI). This error occurs randomly in one container from 12.
 Comment 58: @choopm Can confirm - happened to me too again yesterday and now again just before few seconds.

There were running around 3 docker build commands at one time and this is the result:

```
57  ---> a4d65b2fc73e
58 Step 9/19 : RUN ["crystal", "spec", "--error-on-warnings", "--no-debug"]
59 error creating overlay mount to /var/lib/docker/overlay2/209a7dfb23bbf26404576987d2b3e1e847f3c6afcc328b201afe75f6d8de2639/merged: device or resource busy
63 ERROR: Job failed: exit code 1
```

```
# docker -v
Docker version 19.03.5, build 633a0ea838
# uname -r
4.19.0-6-amd64
```

Can we reopen this issue please? Or should we create new one? This issue clearly isn't resolved yet...
 Comment 59: Our systems run stable since when we use `--max-concurrent-uploads=1` for our `docker:18.09-dind` CI setup. However, after poking around with our buildsystem today I was able to reproduce it by using `DOCKER_BUILDKIT=1` and parallel builds.

I suggest opening a new issue, describing your setup in depth and an example for devs to reproduce. I'm not affiliated in any kind with moby, just trying to help and keeping the noise down on this issue.
 Comment 60: Hey guys, I have faced this problem when I use an external SD Card for my docker application (It is running on arm64v8).
How did I solve it? 
I have updated my docker version to 19.03.9 , formatted the SD Card from ntfs to ext4, edited  /etc/docker/daemon.json like below.
```
{
    "storage-driver":"overlay2",
}
```
It works now !
 Comment 61: After reboot system, I face this issue.  I set centos Selinux(/etc/selinux/config) from disabled to permissive. and reboot again . It works!
 Comment 62: Hi guys, this is still happening:
{'source': 'GithubIssues', 'repo_name_with_owner': 'docker/for-linux', 'issue_id': 462416177, 'repo_stars': 758.0}