Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fatal error: Supervisor has failed, shutting down: Supervisor caught an error: one of the children died: com.docker.driver.amd64-linux (pid: 42742) #3076

Open
natea opened this issue Jul 11, 2018 · 71 comments

Comments

@natea
Copy link

@natea natea commented Jul 11, 2018

  • [x ] I have tried with the latest version of my channel (Stable or Edge)
  • [ x] I have uploaded Diagnostics
  • Diagnostics ID: 20180711-065336

Expected behavior

Actual behavior

Information

I saw this error message pop up:
django_db_utils_operationalerror___1045___access_denied_for_user__xqueue___172_18_0_13__ issue__34 _regisb_openedx-docker

  • macOS Version: 10.13.5 (High Sierra)

Diagnostic logs

Docker for Mac: version: 18.05.0-ce-mac67 (1fa4e2acfc1a52f79623add2390604515d32297e)
macOS: version 10.13.5 (build: 17F77)
logs: /tmp/566AF46F-1653-4F02-8C95-F1381D1814D8/20180711-065336.tar.gz
failure: com.docker.driver.amd64-linux is not running
[ERROR] vpnkit
Unexpected error connecting to /Users/nateaune/Library/Containers/com.docker.docker/Data/s51: (Failure
"Error connecting socket to 9p endpoint unix:/Users/nateaune/Library/Containers/com.docker.docker/Data/s51: Unix.Unix_error(Unix.ENOENT, "connect", "")")
com.docker.vpnkit is not running
[OK] virtualization hypervisor
[OK] vmnetd
[OK] dns
[ERROR] driver.amd64-linux
com.docker.driver.amd64-linux is not running
[OK] virtualization VT-X
[OK] app
[OK] moby
[OK] system
[OK] moby-syslog
[OK] kubernetes
[OK] files
[OK] env
[OK] virtualization kern.hv_support
[ERROR] osxfs
com.docker.osxfs is not running
[OK] moby-console
[OK] logs
[ERROR] docker-cli
Connection refused (ECONNREFUSED) connecting to /var/run/docker.sock: check if service is running
Connection refused (ECONNREFUSED) connecting to /Users/nateaune/Library/Containers/com.docker.docker/Data/docker.sock: check if service is running
docker ps failed
[OK] disk

Docker for Mac: Docker Edge 18.05.0-ce-mac67 (25042)

Steps to reproduce the behavior

  1. ...
  2. ...
@EckoEdc

This comment has been minimized.

Copy link

@EckoEdc EckoEdc commented Jul 22, 2018

Got the same error. The nginx container and docker dies randomly with this error

@jazzdan

This comment has been minimized.

Copy link

@jazzdan jazzdan commented Jul 25, 2018

Resetting Docker to "Factory defaults" fixed this for me, though I didn't have the ENOENT error that you had.

@MikeMitterer

This comment has been minimized.

Copy link

@MikeMitterer MikeMitterer commented Jul 26, 2018

Do they have no quality checks at Docker? Almost every version in the last 10 month crashed and I had to go back to Factory defaults - very annoying

@wojas

This comment has been minimized.

Copy link

@wojas wojas commented Jul 26, 2018

This still happens with edge version 18.06.0-ce-mac69 (26398)

@Stringer86

This comment has been minimized.

Copy link

@Stringer86 Stringer86 commented Jul 27, 2018

also experiencing with higher traffic (nginx & ror)

@vovanmix

This comment has been minimized.

Copy link

@vovanmix vovanmix commented Jul 27, 2018

having the same issue when running rails, nginx and https://github.com/jubos/fake-s3

@Jaxmetalmax

This comment has been minimized.

Copy link

@Jaxmetalmax Jaxmetalmax commented Jul 27, 2018

Same issue while running debian jessie image with RoR

@TimJKStrickland

This comment has been minimized.

Copy link

@TimJKStrickland TimJKStrickland commented Jul 30, 2018

Same issue with RoR

@vovanmix

This comment has been minimized.

Copy link

@vovanmix vovanmix commented Jul 30, 2018

@AshwinRamesh

This comment has been minimized.

Copy link

@AshwinRamesh AshwinRamesh commented Jul 31, 2018

Also experiencing this repeatedly. Can't seem to understand what exactly is causing this. If anyone can give me a heads up, that'd be great :(

@matthewlowry

This comment has been minimized.

Copy link

@matthewlowry matthewlowry commented Aug 1, 2018

For what it's worth: I was having this problem while running Postgres, Elasticsearch, and Riak-KV containers.

What seems to have fixed it for me was:

  • Updating MacOS
  • Reinstalling Docker for Mac from scratch.

Note the in-app update then reset to factory defaults did not fix it. But uninstall then reinstall using current stable seems to have made this go away for me.

Update: Actually ignore this I'm still get hard crashes :(

@AshwinRamesh

This comment has been minimized.

Copy link

@AshwinRamesh AshwinRamesh commented Aug 2, 2018

Yea I tried all of that...

@AshwinRamesh

This comment has been minimized.

Copy link

@AshwinRamesh AshwinRamesh commented Aug 2, 2018

Sorry to hear that @matthewlowry. Does anyone know what exactly causes this? I'm running 4 docker nodes. 1 Zookeeper + 3 Solr Nodes (talking to ZK)

@EckoEdc

This comment has been minimized.

Copy link

@EckoEdc EckoEdc commented Aug 3, 2018

I notice that frequently under "heavy" file serving on my nginx container on Mac. Can t seem to find a good log of it though apart from the "children has died" and "socket doesnt exit anymore".

@paulzhang-ladbrokes

This comment has been minimized.

Copy link

@paulzhang-ladbrokes paulzhang-ladbrokes commented Aug 7, 2018

My colleague got the same issue, roughly twice a day. Waiting for a solution ;)
Running nginx in containers...

@Miroslav-Stopka

This comment has been minimized.

Copy link

@Miroslav-Stopka Miroslav-Stopka commented Aug 9, 2018

Same issue, 2x / 3x a day :(

@rjdavidson

This comment has been minimized.

Copy link

@rjdavidson rjdavidson commented Aug 9, 2018

Same issue, the moment I start any container using any nginx image or a derivative. Tried factory reset, full reinstall Docker, etc. Other containers (e.g. using openresty or php-fpm images) run fine.

@zhongdom

This comment has been minimized.

Copy link

@zhongdom zhongdom commented Aug 9, 2018

same issue。Neither install by brew nor dmg.

@adamkotecki

This comment has been minimized.

Copy link

@adamkotecki adamkotecki commented Aug 13, 2018

Same issue every time I try to run Docker.app on clean installation of OS X 10.13.6
Tired stable and edge version, reset to the factory defaults, etc...
Waiting for solution

P.S. Interesting thing is this error message: "com.docker.driver.amd64-linux" whilst OS X users doesn't have AMD processors.

@wojas

This comment has been minimized.

Copy link

@wojas wojas commented Aug 15, 2018

Diagnose just hangs, so I'm not able to provide a Diagnostic ID, but I attached the relevant log entries from Console.app below. The log starts with:

default	21:09:12.135133 +0800	com.docker.osxfs	Unexpected exception: Socket.Closed
default	21:09:12.135207 +0800	com.docker.osxfs	Unexpected exception: Socket.Closed
default	21:09:12.152275 +0800	com.docker.osxfs	volume: Unix.Unix_error(Unix.EPIPE, "write", "") writing event message
...

Full logs: docker-crash.log

Version 18.06.0-ce-mac69 (26398)
Edge channel, f81dbdd8a1

The problem appears to be somewhere in osxfs, but the logs do not provide sufficient detail.
I suspect it has something to do with filesystem event notifications, as crashes appear to coincide with saving files that are watched inside the containers.

@adamkotecki

This comment has been minimized.

Copy link

@adamkotecki adamkotecki commented Aug 17, 2018

Maybe someone is able to find and share link to older docker installation file which does not have this bug?

@jiubujian

This comment has been minimized.

Copy link

@jiubujian jiubujian commented Aug 20, 2018

enable VT-x, it works on my Hackintosh 10.13.5.

@zhongdom

This comment has been minimized.

Copy link

@zhongdom zhongdom commented Aug 20, 2018

Enable Intel Virtualization Technology can fix this issue.

@Jaxmetalmax

This comment has been minimized.

Copy link

@Jaxmetalmax Jaxmetalmax commented Aug 20, 2018

@zhongdom but all intel based macs have virtualization enabled, and this issue happen in mac too

@max3uc3

This comment has been minimized.

Copy link

@max3uc3 max3uc3 commented Aug 20, 2018

I've been throw the same issue and it was because of a lack of disk space. No problem since I've fixed it.

@chengyin

This comment has been minimized.

Copy link

@chengyin chengyin commented Aug 22, 2018

I also experienced this issue. None of the implication/suggestions seemed to work/matter:

  • Disk space
  • VT-x (N/A for Mac)
  • Reset Docker

It happens consistently for me when running front visual testing, which uses 6 concurrent headless Chrome processes in a container. (High CPU and memory utilization)

@Joshfindit

This comment has been minimized.

Copy link

@Joshfindit Joshfindit commented Aug 27, 2018

Same issue here (OSX), happens when transcoding video with Emby.

Edit: Actually not when watching continuously: normally crashes when skipping through the video multiple times (tap ahead on timeline and miss what I'm looking for > video loads > tap back on timeline and miss what I'm looking for > video may or may not load > tap ahead on timeline > docker has crashed by now)

@kevincolyar

This comment has been minimized.

Copy link

@kevincolyar kevincolyar commented Sep 2, 2018

Same issue. Nginx container serving up mp3 files.

@campaignupgrade

This comment has been minimized.

Copy link

@campaignupgrade campaignupgrade commented Dec 11, 2018

Updating to Version 2.0.0.0-mac81 (29211) seems to have fixed it for me.

@hieunguyentrung

This comment has been minimized.

Copy link

@hieunguyentrung hieunguyentrung commented Dec 12, 2018

Version 2.0.0.0-mac81 (29211) on rMBP 2015 (latest OS)
Still got this problem, when docker raise error, I'm not running any containers, just browersing some website.

@demonguru18

This comment has been minimized.

Copy link

@demonguru18 demonguru18 commented Jan 1, 2019

The problem is caused because - In your Motherboards BIOS settings, you have Intel Virtualization Technology(VT-X) set as Disabled. Please set this option to Enabled and you will no longer see the Supervisor related error. Setting this to disabled, prevents VM's from using/sharing resources. Basically, stops providing hardware assistance for processors running virtualization platforms. If you have both the options VT-D and VT-X set both to Enabled. Im my Motherboard I set both to enabled. Hope this solves the problem, and you don't need to downgrade Docker.

@Paul-Wasilewski

This comment has been minimized.

Copy link

@Paul-Wasilewski Paul-Wasilewski commented Jan 6, 2019

I have managed to solve the problem on OS X (Version 2.0.0.0-mac81) by removing all (my customs) Paths under File Sharing. I have a strong suggestion that it might be a problem when docker.sock is shared between the containers.

@kchowkchowkchow

This comment has been minimized.

Copy link

@kchowkchowkchow kchowkchowkchow commented Jan 23, 2019

The problem is caused because - In your Motherboards BIOS settings, you have Intel Virtualization Technology(VT-X) set as Disabled. Please set this option to Enabled and you will no longer see the Supervisor related error. Setting this to disabled, prevents VM's from using/sharing resources. Basically, stops providing hardware assistance for processors running virtualization platforms. If you have both the options VT-D and VT-X set both to Enabled. Im my Motherboard I set both to enabled. Hope this solves the problem, and you don't need to downgrade Docker.

This!!! For me this fixed it. FYI, for my Asus gryphon the bios settings was in in > Advanced > cpu confirguration.

@joelash

This comment has been minimized.

Copy link

@joelash joelash commented Feb 21, 2019

I'm on a MacBook pro that seems to have VT-X enabled, however I still get this error and 95% of the time the computer immediately kernel panics and reboots. Any thoughts on that?

@chunhei2008

This comment has been minimized.

Copy link

@chunhei2008 chunhei2008 commented Feb 28, 2019

I also experienced this issue. None of the implication/suggestions seemed to work/matter:

  • Disk space
  • VT-x (N/A for Mac)
  • Reset Docker

It happens consistently for me when running front visual testing, which uses 6 concurrent headless Chrome processes in a container. (High CPU and memory utilization)

Intel VT enable ,it works!

@joelash

This comment has been minimized.

Copy link

@joelash joelash commented Feb 28, 2019

@chunhei2008 how did you enabled Intel VT?

@danielb2

This comment has been minimized.

Copy link

@danielb2 danielb2 commented Mar 11, 2019

Same issue here.
Docker 18.09.2, build 6247962 on MacOS Mojave.
Diagnostic hangs.

@danielb2

This comment has been minimized.

Copy link

@danielb2 danielb2 commented Mar 11, 2019

[solved]: enabled VT-d and Intel Virtualization in UEFI

@morberg

This comment has been minimized.

Copy link

@morberg morberg commented Apr 15, 2019

This thread seems to be a mix with people running Hackintoshes where enabling Intel VT seems to help and people running on Apple hardware where no solution is yet found.

I'm running on a Mac Mini and see this issue with docker desktop 2.0.0.3 (31259) at least once a week. Has anybody found a workaround on Apple hardware?

@danielb2

This comment has been minimized.

Copy link

@danielb2 danielb2 commented Apr 15, 2019

@morberg it's going to be related to the motherboard handling virtualization regardless of what you have. Any clues when booting verbose?

@morberg

This comment has been minimized.

Copy link

@morberg morberg commented Apr 22, 2019

@morberg it's going to be related to the motherboard handling virtualization regardless of what you have. Any clues when booting verbose?

What should I do in order to boot verbose and what clues should I look for?

To clarify: I'm running on stock Apple hardware with no OS modifications.

@danielb2

This comment has been minimized.

Copy link

@danielb2 danielb2 commented Apr 22, 2019

@morberg the first search result: https://www.idownloadblog.com/2015/08/17/how-to-boot-your-mac-in-verbose-mode/

How about looking for anything mentioning virtualization ?

@mathsigit

This comment has been minimized.

Copy link

@mathsigit mathsigit commented Jun 18, 2019

The problem is caused because - In your Motherboards BIOS settings, you have Intel Virtualization Technology(VT-X) set as Disabled. Please set this option to Enabled and you will no longer see the Supervisor related error. Setting this to disabled, prevents VM's from using/sharing resources. Basically, stops providing hardware assistance for processors running virtualization platforms. If you have both the options VT-D and VT-X set both to Enabled. Im my Motherboard I set both to enabled. Hope this solves the problem, and you don't need to downgrade Docker.

Enable Intel Virtualization Technology(VT-X) in BIOS works for me.
Thanks a lot!

@docker-desktop-robot

This comment has been minimized.

Copy link
Collaborator

@docker-desktop-robot docker-desktop-robot commented Sep 16, 2019

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@MNMelton

This comment has been minimized.

Copy link

@MNMelton MNMelton commented Sep 16, 2019

/remove-lifecycle stale

@Startouf

This comment has been minimized.

Copy link

@Startouf Startouf commented Oct 14, 2019

I'm running into this issue as well on

  • macOS 10.14.3
  • Docker version 19.03.2, build 6a30dfc

Previously I was running on a version of docker that was completely fine, but after I tried to move my docker image file to a SD card a whole new mess started :

  • My docker was working but the images were taking too much space so..
  • ...I decided to move my main docker images file to a SD card of ~60GB
  • However there was a problem because the docker Image File was actually too big, and docker did not complain before starting the transfer (while the file is sparse on my macOS FS, it is not on my SD card so the default size of 64GB for the Docker image file actually couldn't fit on my SD card. After that Docker kept crashing and I had to reset to defaults
  • On my second attempt, I first changed the image file from 64 to 32Gb, and then moved it to my SD card. It worked well.
  • Following this and a restart, my docker cannot start anymore (it kept staying in the "docker is starting mode").
  • After googling a bit I decided do uninstall docker to reinstall a fresh version. I noticed I had several brew casks left so I brew uninstall docker but despite brew reporting success messages, I still had the docker app still running, and I remembered I had installed docker from an image file, so I just removed Docker by trashing it from my app folder.
  • After reinstalling Docker from the official dmg image from Docker, my docker still won't start but now I have the following error message

one of the sub-processes failed: com.docker.driver.amd64-linux (pid: xxxxx)

  • Even after resetting to factory settings, the same message keeps popping up :'(

And I'm running docker on a genuine MacBook Pro (Retina, 13-inch, Early 2015)

@zixuemeng

This comment has been minimized.

Copy link

@zixuemeng zixuemeng commented Oct 21, 2019

I'm running into this issue as well on

  • macOS 10.14.3
  • Docker version 19.03.2, build 6a30dfc

Previously I was running on a version of docker that was completely fine, but after I tried to move my docker image file to a SD card a whole new mess started :

  • My docker was working but the images were taking too much space so..
  • ...I decided to move my main docker images file to a SD card of ~60GB
  • However there was a problem because the docker Image File was actually too big, and docker did not complain before starting the transfer (while the file is sparse on my macOS FS, it is not on my SD card so the default size of 64GB for the Docker image file actually couldn't fit on my SD card. After that Docker kept crashing and I had to reset to defaults
  • On my second attempt, I first changed the image file from 64 to 32Gb, and then moved it to my SD card. It worked well.
  • Following this and a restart, my docker cannot start anymore (it kept staying in the "docker is starting mode").
  • After googling a bit I decided do uninstall docker to reinstall a fresh version. I noticed I had several brew casks left so I brew uninstall docker but despite brew reporting success messages, I still had the docker app still running, and I remembered I had installed docker from an image file, so I just removed Docker by trashing it from my app folder.
  • After reinstalling Docker from the official dmg image from Docker, my docker still won't start but now I have the following error message

one of the sub-processes failed: com.docker.driver.amd64-linux (pid: xxxxx)

  • Even after resetting to factory settings, the same message keeps popping up :'(

And I'm running docker on a genuine MacBook Pro (Retina, 13-inch, Early 2015)

I have encountered the same problem,is there any solution?

@demonguru18

This comment has been minimized.

Copy link

@demonguru18 demonguru18 commented Oct 25, 2019

The problem is caused because - In your Motherboards BIOS settings, you have Intel Virtualization Technology(VT-X) set as Disabled. Please set this option to Enabled and you will no longer see the Supervisor related error. Setting this to disabled, prevents VM's from using/sharing resources. Basically, stops providing hardware assistance for processors running virtualization platforms. If you have both the options VT-D and VT-X set both to Enabled. Im my Motherboard I set both to enabled. Hope this solves the problem, and you don't need to downgrade Docker.

I'm running into this issue as well on

  • macOS 10.14.3
  • Docker version 19.03.2, build 6a30dfc

Previously I was running on a version of docker that was completely fine, but after I tried to move my docker image file to a SD card a whole new mess started :

  • My docker was working but the images were taking too much space so..
  • ...I decided to move my main docker images file to a SD card of ~60GB
  • However there was a problem because the docker Image File was actually too big, and docker did not complain before starting the transfer (while the file is sparse on my macOS FS, it is not on my SD card so the default size of 64GB for the Docker image file actually couldn't fit on my SD card. After that Docker kept crashing and I had to reset to defaults
  • On my second attempt, I first changed the image file from 64 to 32Gb, and then moved it to my SD card. It worked well.
  • Following this and a restart, my docker cannot start anymore (it kept staying in the "docker is starting mode").
  • After googling a bit I decided do uninstall docker to reinstall a fresh version. I noticed I had several brew casks left so I brew uninstall docker but despite brew reporting success messages, I still had the docker app still running, and I remembered I had installed docker from an image file, so I just removed Docker by trashing it from my app folder.
  • After reinstalling Docker from the official dmg image from Docker, my docker still won't start but now I have the following error message

one of the sub-processes failed: com.docker.driver.amd64-linux (pid: xxxxx)

  • Even after resetting to factory settings, the same message keeps popping up :'(

And I'm running docker on a genuine MacBook Pro (Retina, 13-inch, Early 2015)

The problem is caused because - In your Motherboards BIOS settings, you have Intel Virtualization Technology(VT-X) set as Disabled. Please set this option to Enabled and you will no longer see the Supervisor related error. Setting this to disabled, prevents VM's from using/sharing resources. Basically, stops providing hardware assistance for processors running virtualization platforms. If you have both the options VT-D and VT-X set both to Enabled. Im my Motherboard I set both to enabled. Hope this solves the problem, and you don't need to downgrade Docker.

@morberg

This comment has been minimized.

Copy link

@morberg morberg commented Oct 25, 2019

I had this exact same error for months and it had nothing to do with virtualization settings for the motherboard. (I don’t know where to change those setting for a genuine Mac. I suspect this only applies to Hackintoshes.)

My issue was caused by a bad SSD. Disk Utility found problems with my file system. Once the disk was reformatted (it couldn’t be repaired in DU) the docker issue went away.

@Diamond0728

This comment has been minimized.

Copy link

@Diamond0728 Diamond0728 commented Oct 27, 2019

Same problem on my macbookpro , with Catalina, I have already try many docker version. It doesnt work

@Diamond0728

This comment has been minimized.

Copy link

@Diamond0728 Diamond0728 commented Oct 31, 2019

Same problem on my macbookpro , with Catalina, I have already try many docker version. It doesnt work

Sometimes after my rebooting, I start docker-desktop for Mac without any application opened else. Docker runes well for few minutes, and I could pull images or run containers during it. But few minutes later, it throw this error again. Anyone else same as me?

@vosscodes

This comment has been minimized.

Copy link

@vosscodes vosscodes commented Dec 12, 2019

same issue on a macbook pro, resolved with a full reinstall of docker from the same .dmg

@docker-desktop-robot

This comment has been minimized.

Copy link
Collaborator

@docker-desktop-robot docker-desktop-robot commented Mar 11, 2020

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.