Closed natea closed 4 years ago
Got the same error. The nginx container and docker dies randomly with this error
Resetting Docker to "Factory defaults" fixed this for me, though I didn't have the ENOENT
error that you had.
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
This still happens with edge version 18.06.0-ce-mac69 (26398)
also experiencing with higher traffic (nginx & ror)
having the same issue when running rails, nginx and https://github.com/jubos/fake-s3
Same issue while running debian jessie image with RoR
Same issue with RoR
I was able to fix it by adding a nginx container in front of the others and adding a rate limiting to 7 req/sec, with failing all other requests. it’s an ugly workaround though. Also this error seem to happen only locally and when accessing the container from the local network by computer IP. Localhost works fine.
On July 30, 2018 at 3:15:29 PM, Tim JK Strickland (notifications@github.com) wrote:
Same issue with RoR
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/docker/for-mac/issues/3076#issuecomment-409029644, or mute the thread https://github.com/notifications/unsubscribe-auth/AG8TmmWASMYIlqE-vTQsDBF5CtvEQGUAks5uL4WBgaJpZM4VK7QC .
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 :(
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:
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 :(
Yea I tried all of that...
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)
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".
My colleague got the same issue, roughly twice a day. Waiting for a solution ;) Running nginx in containers...
Same issue, 2x / 3x a day :(
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.
same issue。Neither install by brew
nor dmg
.
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.
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.
Maybe someone is able to find and share link to older docker installation file which does not have this bug?
enable VT-x, it works on my Hackintosh 10.13.5.
Enable Intel Virtualization Technology
can fix this issue.
@zhongdom but all intel based macs have virtualization enabled, and this issue happen in mac too
I've been throw the same issue and it was because of a lack of disk space. No problem since I've fixed it.
I also experienced this issue. None of the implication/suggestions seemed to work/matter:
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)
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)
Same issue. Nginx container serving up mp3 files.
Same issue here. Just downloaded Docker, can't even set it up. Edge version has the same issue as well. The weird thing is the same issue doesn't happen on my Macbook.
Same issue here (OSX) with latest stable version (18.06.1-ce-mac73 (26764)). Reset, reinstall and restart didn't fixed it. I found out, that this always happens for me if an external Request comes in. I'm trying to implement Klarna (payment service provider) and configured port mapping in my router with dynamic dns domain. This error always occurs when Klarna sends a request to my computer.
My issue seems similar to @lin4you 's. It appears to be network related (ipv6 maybe?).
Previously, I was using an Airport Extreme router and was having my internet quit ever other day along with Docker crashing. Since switching to a different router, which still port forwards to my Docker for Mac, I haven't had issues since with my internet connection or Docker.
I don't have an explicit solution but it appears to have been related to my network.
same here. reset can only fix this temporarily
Happens every 1-2 hr once i start my docker. Really frustrating.
I saw this issues right after upgrading some minor stuff on OS X. "Reset Docker to factor defaults" option helped to fix this issue.
I am getting this error in Mac OS version 10.13.6. Nothing in the diagnostic logs, the diagnostic window get stuck all the time. Couldn't start the docker app due to this issue. "Reset Docker to factor defaults" button didn't help. Please help if someone resolved this issue
Same issue here. Docker 18.06.1-ce-mac73 on MacOS Mojave. Diagnostic hangs.
Same issue as well. Docker Docker version 18.06.1-ce, build e68fc7a on MacOS Mojave. Reset Docker to factory defaults does not help.
Diagnostic window hangs but running diagnostics from the terminal does work (although I see no error in those diagnostic logs..): Diagnostics ID: 2FC42A1C-77B6-46B1-A9CA-43CCE06787A8/20181015184642
Ah excuses. My issue was that I had by mistake not enabled Intel Hardware Virtualization in my BIOS. Enabled that and Docker runs fine now.
To add a datapoint: Hardware Virtualization has been enabled on mine the whole time.
same
I had the same problem, after enabled VT-d
it works
how?where enabled VT-d? thanks @ohmyhusky
Same here, diagnostics hangs so I can't get an ID.
Factory reset did not help.
Version 18.06.1-ce-mac73 (26764)
Channel: stable
b0f14f1dac
crash log
Process: com.docker.osxfs [2851]
Path: /Applications/Docker.app/Contents/MacOS/com.docker.osxfs
Identifier: com.docker.osxfs
Parent Process: com.docker.supervisor [2850]
Responsible: com.docker.osxfs [2851]
com.docker.osxfs(2851,0x110fc75c0) malloc: Incorrect checksum for freed object 0x7fda7ab06458: probably modified after being freed.
10 com.docker.osxfs 0x0000000101013239 lwt_unix_malloc + 9
11 com.docker.osxfs 0x0000000100ffebed lwt_prefix__4_lstat + 77
12 com.docker.osxfs 0x0000000100dacad4 camlUnix_sys_stat_lwt_generated__fun_2403 + 116
13 com.docker.osxfs 0x0000000100dad166 camlSys_stat_unix_lwt__lstat_1365 + 134
14 com.docker.osxfs 0x0000000100d9b780 camlOsxfs_server__fun_13493 + 176
15 com.docker.osxfs 0x0000000100ec9d00 camlFuse__respond_with_entry_inner_4933 + 112
16 com.docker.osxfs 0x0000000100d9cb14 camlOsxfs_server__fun_13981 + 148
17 com.docker.osxfs 0x0000000100f96aec camlLwt__catch_1739 + 44
18 com.docker.osxfs 0x0000000100f96aec camlLwt__catch_1739 + 44
19 com.docker.osxfs 0x0000000100d610ca camlOsxfs__fun_8571 + 42
20 com.docker.osxfs 0x0000000100f977a5 camlLwt__async_1804 + 37
21 com.docker.osxfs 0x0000000100d6106a camlOsxfs__fun_8561 + 90
22 com.docker.osxfs 0x0000000100f966c6 camlLwt__fun_2770 + 86
23 com.docker.osxfs 0x0000000100f94d47 camlLwt__run_waiters_rec_1390 + 119
24 com.docker.osxfs 0x0000000100f94d47 camlLwt__run_waiters_rec_1390 + 119
25 com.docker.osxfs 0x0000000100f94d47 camlLwt__run_waiters_rec_1390 + 119
26 com.docker.osxfs 0x0000000100f94d47 camlLwt__run_waiters_rec_1390 + 119
27 com.docker.osxfs 0x0000000100f94d47 camlLwt__run_waiters_rec_1390 + 119
28 com.docker.osxfs 0x0000000100f94d47 camlLwt__run_waiters_rec_1390 + 119
29 com.docker.osxfs 0x0000000100f9508c camlLwt__safe_run_waiters_1455 + 44
30 com.docker.osxfs 0x0000000100f941dd camlLwt_sequence__loop_1061 + 45
31 com.docker.osxfs 0x00000001010455cc caml_start_program + 92
32 com.docker.osxfs 0x000000010103ffc9 caml_callback + 9
34 com.docker.osxfs 0x000000010101adbe lwt_libev_loop + 62
35 com.docker.osxfs 0x0000000100f71859 camlLwt_engine__fun_2860 + 105
36 com.docker.osxfs 0x0000000100f74818 camlLwt_main__run_1125 + 136
37 com.docker.osxfs 0x0000000100d62899 camlOsxfs__serve_5574 + 1145
38 com.docker.osxfs 0x0000000100d77e18 camlCmdliner_term__fun_1416 + 104
39 com.docker.osxfs 0x0000000100d7a76d camlCmdliner__fun_2390 + 13
40 com.docker.osxfs 0x0000000100d7adba camlCmdliner__run_1502 + 170
41 com.docker.osxfs 0x0000000100d7b05c camlCmdliner__term_eval_1550 + 300
42 com.docker.osxfs 0x0000000100d7bd15 camlCmdliner__eval_choice_inner_2477 + 325
43 com.docker.osxfs 0x0000000100d635e7 camlOsxfs__entry + 2247
44 com.docker.osxfs 0x0000000100d5aa49 caml_program + 5065
45 com.docker.osxfs 0x00000001010455cc caml_start_program + 92
46 com.docker.osxfs 0x0000000101026e2c caml_startup_common + 524
47 com.docker.osxfs 0x0000000101026e9b caml_main + 11
48 com.docker.osxfs 0x0000000101026f0c main + 12
2 com.docker.osxfs 0x000000010101a0bb worker_loop + 155
2 com.docker.osxfs 0x000000010101a0bb worker_loop + 155
10 com.docker.osxfs 0x0000000101007a2e osx_cf_run_loop_run + 14
11 com.docker.osxfs 0x000000010100822b caml__21_osx_cf_run_loop_run + 11
12 com.docker.osxfs 0x0000000100e319c3 camlCf_generated__fun_3377 + 19
13 com.docker.osxfs 0x0000000100dbbd37 camlCf_lwt__fun_1564 + 295
14 com.docker.osxfs 0x0000000100e37cf9 camlThread__fun_1571 + 137
15 com.docker.osxfs 0x00000001010455cc caml_start_program + 92
16 com.docker.osxfs 0x000000010100a248 caml_thread_start + 104
1 com.docker.osxfs 0x000000010100a2af caml_thread_tick + 79
2 com.docker.osxfs 0x000000010101a0bb worker_loop + 155
0x100d58000 - 0x1010c1fff +com.docker.osxfs (0) <DC14879A-A462-328E-9B7D-B6449D336507> /Applications/Docker.app/Contents/MacOS/com.docker.osxfs
0x101538000 - 0x10153dfff +libffi.6.dylib (0) <B6E35501-D66B-31ED-B55E-6C131255CDA1> /Applications/Docker.app/Contents/Resources/lib/libffi.6.dylib
0x10154c000 - 0x101554ff3 +libev.4.dylib (0) <BE7FC6A9-9EF6-3790-9812-461647F70C51> /Applications/Docker.app/Contents/Resources/lib/libev.4.dylib
Process: com.docker.osxfs [3128]
Path: /Applications/Docker.app/Contents/MacOS/com.docker.osxfs
Identifier: com.docker.osxfs
Parent Process: com.docker.supervisor [3127]
Responsible: com.docker.osxfs [3128]
__TEXT 000000010358c000-00000001038f6000 [ 3496K] r-x/rwx SM=COW /Applications/Docker.app/Contents/MacOS/com.docker.osxfs
3 com.docker.osxfs 0x000000010384edb1 lwt_libev_loop + 49
4 com.docker.osxfs 0x00000001037a5859 camlLwt_engine__fun_2860 + 105
5 com.docker.osxfs 0x00000001037a8818 camlLwt_main__run_1125 + 136
6 com.docker.osxfs 0x0000000103596899 camlOsxfs__serve_5574 + 1145
7 com.docker.osxfs 0x00000001035abe18 camlCmdliner_term__fun_1416 + 104
8 com.docker.osxfs 0x00000001035ae76d camlCmdliner__fun_2390 + 13
9 com.docker.osxfs 0x00000001035aedba camlCmdliner__run_1502 + 170
10 com.docker.osxfs 0x00000001035af05c camlCmdliner__term_eval_1550 + 300
11 com.docker.osxfs 0x00000001035afd15 camlCmdliner__eval_choice_inner_2477 + 325
12 com.docker.osxfs 0x00000001035975e7 camlOsxfs__entry + 2247
13 com.docker.osxfs 0x000000010358ea49 caml_program + 5065
14 com.docker.osxfs 0x00000001038795cc caml_start_program + 92
15 com.docker.osxfs 0x000000010385ae2c caml_startup_common + 524
16 com.docker.osxfs 0x000000010385ae9b caml_main + 11
17 com.docker.osxfs 0x000000010385af0c main + 12
2 com.docker.osxfs 0x000000010384e0bb worker_loop + 155
2 com.docker.osxfs 0x000000010384e0bb worker_loop + 155
10 com.docker.osxfs 0x000000010383ba2e osx_cf_run_loop_run + 14
11 com.docker.osxfs 0x000000010383c22b caml__21_osx_cf_run_loop_run + 11
12 com.docker.osxfs 0x00000001036659c3 camlCf_generated__fun_3377 + 19
13 com.docker.osxfs 0x00000001035efd37 camlCf_lwt__fun_1564 + 295
14 com.docker.osxfs 0x000000010366bcf9 camlThread__fun_1571 + 137
15 com.docker.osxfs 0x00000001038795cc caml_start_program + 92
16 com.docker.osxfs 0x000000010383e248 caml_thread_start + 104
1 com.docker.osxfs 0x000000010383e2af caml_thread_tick + 79
2 com.docker.osxfs 0x000000010384e0bb worker_loop + 155
0x10358c000 - 0x1038f5fff +com.docker.osxfs (0) <DC14879A-A462-328E-9B7D-B6449D336507> /Applications/Docker.app/Contents/MacOS/com.docker.osxfs
0x103d6b000 - 0x103d70fff +libffi.6.dylib (0) <B6E35501-D66B-31ED-B55E-6C131255CDA1> /Applications/Docker.app/Contents/Resources/lib/libffi.6.dylib
0x103d7e000 - 0x103d86ff3 +libev.4.dylib (0) <BE7FC6A9-9EF6-3790-9812-461647F70C51> /Applications/Docker.app/Contents/Resources/lib/libev.4.dylib
how?where enabled VT-d? thanks @ohmyhusky
In BIOS settings
Updating to Version 2.0.0.0-mac81 (29211) seems to have fixed it for me.
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.
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 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.
Expected behavior
Actual behavior
Information
I saw this error message pop up:
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
Steps to reproduce the behavior