encountered an error during hcsshim::System::waitBackground: failure in in windows container mode. on fast ring and latest 1909 release. #813
Comments
|
I can reproduce on same versions. Seems to be a LCOW only issue. Works fine when engine is Linux (with WSL2 backend) |
|
I can reproduce as well, running Windows: 19608.1006 |
Correct, no issue if the engine is set to Linux, we need the docker context @simonferquel |
|
Same for me on 1909 |
|
I see have the same on the stable channel |
|
Windows 10.0.19041.208 |
|
I see have the same on the version stable. |
|
Same here across 3 different computers. |
|
They broke it with version 2.2.0.4. Uninstalling Docker Desktop and installing version 2.2.0.3 resolved the issue. Noticed that they added a "Known issue" to the release notes for 2.2.0.4 saying: Funny way of saying we broke the most fundamental thing of LCOW, please use a virtual machine instead. |
LCOW is great but lingering at the moment. I did create a roadmap ticket because many people are using LCOW at the moment. docker/roadmap#79 |
|
Sad part is that this was working just 2 0.0.0.x versions ago. Completely breaking a feature as important as LCOW (even an experimental one) and putting a small aside in the release notes as "some cli commands fail" is pretty ridiculous. |
ghost
mentioned this issue
|
The command '/bin/sh -c apk add --update redis' returned a non-zero code: 4294967295: failed to shutdown container: container a0ec71fb66524cdd30fd9e3ff1501afa288ba6c51bea2255976faaad9889f6f0 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container a0ec71fb66524cdd30fd9e3ff1501afa288ba6c51bea2255976faaad9889f6f0 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110) i am having this error anyone can solve this ? |
|
I have same error on windows. It happens always when dockerfile uses "RUN" command. |
|
The same happen with Windows containers, not only with LCOW. It work most of the time but sometime, a docker run fail with this message. |
|
I met the same error with the official "Getting Started" docker tutorial. It happens in windows and linux containers too. |
|
I don't think there is any solution for now. I just use a virtualbox now. |
|
It happen with WCOW and LCOW. For linux, of course there is alternative like WSL2 or Hyper-V. But with Windows, there is no alternative. |
|
Issue is present on server 2019 insider version 2004 build 20236.1000 Tested Docker 2.4.0.0 and Docker 2.4.1.0 |
|
I uninstalled and re-installed the latest version of the docker. It seems it is working now under WSL2. |
|
Does not work for me on the latest Docker 2.4.0.0 and 2004 with WSL2 |
|
This happens for me when I include more than one volume definition in the compose. |
|
I am still seeing this with
|
|
Still an issue on
Simple example:
Dockerfile Result: |
|
Downloaded from public: http://maven.aliyun.com/nexus/content/groups/public/org/apache/commons/commons-compress/1.20/commons-compress-1.20.jar (632 kB at 108 kB/s) Me too， is there any solution to resolve this. |
|
I just blindly accepted an update to Docker Desktop -- apparently I shouldn't have done that. Seeing the same issue.
|
I re-pulled the image I was using and now things are good |
|
The command '/bin/sh -c npm install' returned a non-zero code: 4294967295: failed to shutdown container: |
how to resolve this issue? |
|
I have noticed that I will always get this error if my docker-compose file has a path with spaces in it. Why? Who knows. I want a volume pointing to where my MDF files live in SQL Server Management Studio. Single quotes don't work either for Windows Containers. |
|
Also happens on dockerEE which version greater than 19.03.5 so it could be fixed by force downgrading the dockerEE version on Server 2019 |
Thanks @Kagamia - I had the same issue with Docker EE on Server 2019 and this works. How did you find that version? I tested downgrading to the versions returned using |
|
@danriggs I'm moving my personal server these days, my old server happen to installed 19.03.5 and it still works for WSL image build, so I tried every minor version on new server ONE-BY-ONE and finally got the last working version. |
|
I've just confirmed that this can still fail on 19.03.5 when building a windows container that has a RUN command in it. It's always been really flaky though on all versions - you think you've found a fix then a few builds later it happens again. |
|
Also happening here, Client: Server: Docker Desktop 4.5.1 (74721) Quite a pain to use Windows containers. |
This is still a problem in |
|
Was this ever solved? |
|
For windows server 2022 docker ee version 19.03.5 did work for me for 1 day, then it stopped, giving a slightly different error: Does anyone have a fix? |
|
A reboot of the device was a functional workaround for me. |
|
For me, a workaround in our CI (Team City) was to ignore the error, and immediately retry again, which skipped all the cached steps, and jumped straight to the problematic step that was giving the error. The 2nd time it worked successfully. Been monitoring this for about 10 builds with consistently successful results. |
|
Yes, this has been going on for years and there has never been any fix for this, it's just really flaky, so people keep announcing they have found a work around because it works once, then they try again and it fails again. In our CI build we have it retrying 5 times, and sometimes it still fails, and every time it fails, it hangs for 10 minutes before failing. Combine that with the enormous size of some Windows container images and you end up with a CI build that can take over an hour and still fail sometimes, just to run docker build, which should take seconds. Windows containers are just awful in general. Avoid them like the plague if you can. Even if you get one to work it takes much longer to spin up a windows host to run one on, clouds tend to have less availability of Windows nodes so you hit capacity issues earlier, features are often missing from cloud hosting options when running Windows containers, and Windows containers are not secure. If you have anything tied to Windows-specific tech, just run that in a container, secure it away as well as you can from the outside world, and run Linux containers for everything else. |
|
What about the proposed experimental WSL2. |
|
For us it happens when building a Windows container so the version of WSL does not make any difference, as it happens in Windows container mode. I run docker desktop for Windows in WSL2 mode and when I build Windows containers this can still happen on any RUN command in the dockerfile. Happens to us on desktop development environments and server build environments. |
|
I really would like that we wouldn't need to use Windows containers, or at very least, why don't we get a proper PowerShell based tool that actually works, without all these Docker issues |
|
Hey, -v D:/Jenkins/jenkins_agent1/workspace/multipip_test_master/:D:/Jenkins/jenkins_agent1/workspace/multipip_test_master/ which is windows pathing, and cannot be adapted to linux as far as I know (I cannot edit to add // instead of /) Am I just not going to be able to use jenkins+docker at all? |
|
I'm facing this issue while building an image using the python package of docker. Here is my code, it gives me an error from line number 4 image="alpine/git:latest"
repo_dir="repos/CryptoTerminal"
client = docker.from_env()
client.images.build(path=repo_dir) # Build gives error
client.containers.create(image) |
|
Just a heads up. I was trying to address some possible HNS issues fixed in/around the KB5018485 timeframe and ended up experimenting with the registry keys here. I wasn't expecting these keys to make an impact on our image pull/rm times, but we noticed a significant improvement on 2019 LTSC with them in place (4x faster |
and others
Description
encountered an error during hcsshim::System::waitBackground: failure in in windows container mode. on fast ring and latest 1909 release.
see also moby moby/moby#40844
Steps to reproduce the issue:
Describe the results you received:
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:23:10 2020
OS/Arch: windows/amd64
Experimental: true
docker version
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.24)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:37:20 2020
OS/Arch: windows/amd64
Experimental: true
docker info
Client:
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
mutagen: Synchronize files with Docker Desktop (Docker Inc., testing)
Server:
Containers: 6
Running: 1
Paused: 0
Stopped: 5
Images: 359
Server Version: 19.03.8
Storage Driver: windowsfilter (windows) lcow (linux)
Windows:
LCOW:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 19608 (19608.1000.amd64fre.rs_prerelease.200410-1438)
Operating System: Windows 10 Pro Version 2004 (OS Build 19608.1006)
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 31.88GiB
Name: PCI
ID: KUM5:H6SV:J3EE:5FI3:Q5PL:TA2W:ZRIS:CNBG:52AF:EL3B:F7DB:H6SG
Docker Root Dir: C:\ProgramData\Docker
Debug Mode: true
File Descriptors: -1
Goroutines: 35
System Time: 2020-04-22T10:03:27.9886332+02:00
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
PS /> exit
time="2020-04-22T10:13:36+02:00" level=error msg="Error waiting for container: failed to shutdown container: container 55b3e99dc6bfda03d6e0be4ec000f5c6c3ee29e8d973389b0d3f1dbaea6cdaf4 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container 55b3e99dc6bfda03d6e0be4ec000f5c6c3ee29e8d973389b0d3f1dbaea6cdaf4 encountered an error during hcsshim::System::waitBackground: failure
in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)"
docker version
Client: Docker Engine - Community
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:23:10 2020
OS/Arch: windows/amd64
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.24)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:37:20 2020
OS/Arch: windows/amd64
Experimental: true
docker info
Client:
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
Server:
Containers: 7
Running: 1
Paused: 0
Stopped: 6
Images: 377
Server Version: 19.03.8
Storage Driver: windowsfilter (windows) lcow (linux)
Windows:
LCOW:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 18363 (18362.1.amd64fre.19h1_release.190318-1202)
Operating System: Windows 10 Enterprise Version 1909 (OS Build 18363.752)
OSType: windows
Architecture: x86_64
CPUs: 12
Total Memory: 31.81GiB
Name: LT-BAP-T-NL
ID: AVXB:O6GT:DLC7:DZXN:OF46:3QIY:GANI:BMDV:R2TY:LN27:ZH44:YZ6X
Docker Root Dir: C:\ProgramData\Docker
Debug Mode: true
File Descriptors: -1
Goroutines: 49
System Time: 2020-04-22T10:13:53.2893047+02:00
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine
cc: @StefanScherer , @simonferquel
The text was updated successfully, but these errors were encountered: