-
Notifications
You must be signed in to change notification settings - Fork 4
Docker ‐ Common Issues on Windows
Sometimes, container creation fails with the error message being that it can't find setup.sh or one of the Gradle modules on the specified path. This is because your files' line endings are CRLF whereas they need to be LF, since they're intended to run on an emulated Linux OS.
Convert the erroring files, but preferably the whole repository, to use LF endings.
If you're not working with projects that need to run in Windows, since this is a global settings change, you should run git config --global core.autocrlf false in Git Bash so that it doesn't auto-convert LF files into CRLF whenever you clone the repo.
These sometimes occur because you're using the wrong type of container, i.e. they're set to emulate Windows instead of Linux.
Using Docker Desktop, when you right click on its hidden icon, select "Switch to Linux containers..." If you are already using Linux, this will say "Switch to Windows containers..." instead.
WARNING: If you notice Docker maximizing your disk's I/O (read and write) bandwidth for a prolonged amount of time, the recommended practice is to force shut down your computer even if you have unsaved work. Severe thrashing can corrupt your host system, especially any running software!
When this happens, don't bother trying to kill Docker. With all read/write bandwidth occupied by the containers, your computer is likely so slow that it would take a long time to do so — the longer you wait, the higher the likelihood of damage.
The reason why this happens is because you didn't allocate enough memory to the Docker VM. Hyper-V works by pre-allocating all of the memory; this means that the allocated RAM can't be used by the rest of the host while the VM is online, and the RAM amount doesn't dynamically update when the VM runs out of available memory for itself. When the second occurs, this means that the VM must rely on a swap space if Docker is configured to provide it.
The swap space is the Linux equivalent of Windows' paging file, also known as virtual memory, the function of which is based on making use of your storage drive as supplementary RAM. When the available physical memory is way too low, there's a noticeable hike in disk I/O for this reason.
The minimum you should allocate is 4 GB. The containers were observed to run on ~3.58 GB RAM utilization while idle.
Through Hyper-V Manager:
- On the leftmost panel, find your computer name. Click on it.
- In the middle panel (Virtual Machines), click on DockerDesktopVM. If you just installed Docker and never used a Hyper-V VM for anything else, this is likely the only option you'll have.
- In the rightmost panel (Actions), ignore everything under the [computer name] tab. Click on Settings under DockerDesktopVM.
- In the window that pops out, click on Memory.
- In the topmost option, labelled "Specify the amount of memory that this virtual machine can use", specify 4096 or above. Take care because the unit used is a MB, not a GB. Make sure that you leave enough memory for your system to run.
Through Docker Desktop:
- Open Settings from the top of the window.
- Switch to Resources.
- Under Memory Limit, change the RAM slider to 4 GB or above. If Docker isn't giving you this option, that most likely means that your computer's maximum RAM is too low. In that case, the recommended action is to upgrade your hardware.
If you're getting one of these errors:
'DockerDesktopVM' could not initialize memory: Not enough memory resources are available to complete this operation (0x8007000E)
Or
'DockerDesktopVM' Microsoft Video Monitor: Failed to finish reserving resources with Error 'Unspecified error' (0x80004005)
This means that you don't have enough free memory in your system to commit pre-allocated memory to the Docker Engine. However, it sometimes fails even when you do, but the resulting in-use memory would be very close to the system limit, i.e. if you have 16 GB total installed, and running software on your system is already using 9 GB, and you set Hyper-V to allocate 6 GB to the VM (bringing it to 15/16 GB utilization), you may see these errors.
This solution will only work if your RAM is able to support both the baseline Windows system and Docker itself.
Close all non-critical running applications and services, and let the Docker Engine finish launching before you consider reopening them. The last step is not recommended if you'd hit the system max doing so.
IntelliJ in particular should be restarted after every pull that causes Gradle to rebuild the project model, because the memory that it reserves typically doesn't get released until you do.
If the run terminal stops updating for a prolonged amount of time, this doesn't mean that Docker is stuck/unable to set up your containers. IntelliJ sometimes stops auto-refreshing it for an unknown reason.
Bear in mind that Gradle generally does take a bit of time to build the project on Docker, so this is not a problem if you notice it stalling for a couple of minutes. Stalling for longer than 15-20 minutes, or appearing like it does, might indicate a problem with your terminal window.
Click on the terminal or write something in it if you can. This causes IntelliJ to refresh it and continue printing out the rest of the logs.
If this doesn't work, Docker Desktop lets you see the history of console logs of a running container. It's worth taking a look there and determining whether Docker's logs are stuck on the same process. If they are, that indicates a different kind of issue.
If your Minecraft multiplayer screen is stuck pinging your LOCALHOST server forever, that's usually an issue with the Minestom server not starting properly. This has happened before we set up Docker, but it's now a bit trickier to terminate in Docker itself as it's capable of making its entire container unkillable.
If docker stop [container name] and docker kill [container name] don't work for you and send you an error message like Error response from daemon: Could not kill running container [container ID], cannot remove - tried to kill container, but did not receive an exit event, you're likely having this issue. Another symptom is the Minestom server container not being assigned a local IP.
The stop command (not the Docker one) not working is expected for any server-related issue; it's reliant on the Minestom server shutting itself down first, which it often can't while it's erroring.
The only solution we found that works is to restart the entire Docker Engine.
If you're having one of the above issues but the respective solution didn't work for you, Windows Defender's Real-Time Protection feature is known in the Docker community to cause problems.
No matter what it says, you can't disable it through Windows settings. To actually disable it, follow a guide online for the Local Group Policy Editor method (if you have a Professional edition) or alternatively, the Registry Editor method.