docker installation fails E: Can not write log(Is /dev/pts mounted?) #85
Comments
|
Seems to be related to #80. I'm not convinced that the log error is causing docker to fail to install (but what do I know, I'm just some random guy on the Internet), but it nevertheless isn't working, just as you say. |
|
The logs error is known and is a red herring, sorry. Docker does not run on WSL at this time. it is something on our radar but not something we want to talk about quite yet. That said, if someone wants to play with Docker here's what they will see:
While it says the Docker service is started, don't be fooled:
|
|
@russalex You've managed to run |
|
@russalex it'd be interesting to see how you overcame upstart ... |
|
Hate to say it, but I did nothing special for upstart. Before running this test I uninstalled using lxrun /uninstall, then did my usual round of apt-get installs for update, upgrade, build-essential, git and ruby. After that I just followed the instructions on the webpage. What I believe you're seeing is an error that was a result of #143. Running docker with the apt-get fixes on that thread it looks like: |
|
Thanks for the heads up. Even though the service seems to start at my end, something else must be broken, as not even
info or help are displayed. I guess this got to do with docker itself which requires Kernel 3.10+. Is there any chance we get a more recent kernel for WSL? Coming from computer science, I really think the ability to run docker containers and any other linux tools could really boost bioinformatics, where there are also a lot of non-computer-affine people :) |
|
WSL isn't a Linux kernel, it's an emulation layer. Though good question what kernel ABI version is being targeted. Presumably things may need to be updated a bit when the Ubuntu version gets |
|
Someone made the Docker work? |
|
The docker engine is not a supported scenario in the short term. I would suggest hitting our User Voice page and upvoting Docker if you're looking to run the docker engine. The docker client however should be running in build 14342. I have been able to run the docker client and connect to a docker engine running in a VM. |
|
To help future work, here is my investigation. issues:
The strace reveal invalid argument on setsockopt: value 1 as Boolean flag seems fine for SO_BROADCAST when looking at |
|
@russalex - we can't upvote Docker on UserVoice.. it is locked :( |
|
For what it's worth: A big piece of docker-engine actually lives inside the kernel itself. That's why it keeps requiring newer kernels. (The docker-engine process doesn't actually do a whole lot itself when running a container; its job is to tell the kernel what to do, the kernel does the real work.) WSL is a clean-room kernel reimplementation. So it can't, for both technical and legal reasons, simply take the kernel components of Docker and "make it work". They would need to reverse-engineer years of ongoing kernel development and reimplement it. (Or take some other nontrivial approach.) If I were a WSL dev (which I'm not), I would totally enjoy that project. But it would take me a huge amount of time, time that could be spent building many other big features. |
|
@aseering Great explanation. Without making any promises I can say that we know docker is an important and powerful too and definitely something we're looking into. |
|
I can confirm the issue from May posted by @yarmand is still the same as it is today. $ docker -D info
Cannot connect to the Docker daemon. Is the docker daemon running on this host?$ sudo docker daemon
can't create unix socket /var/run/docker.sock: listen unix /var/run/docker.sock: setsockopt: invalid argument$ sudo strace docker daemon
...
setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = -1 EINVAL (Invalid argument)
close(4) = 0
... |
|
It seems like (1) supporting windows server containers in Windows 10 and (2) using Windows Docker from Windows Bash (already working) would be acceptable. |
|
@bbarker I do not understand the benefit you are describing. Being able to run docker client inside WSL in order to run a windows app as a container looks a bit overcomplicated to me. It also seems the first error we are blocking on here, is a better support for sockets into WSL, which will be a good thing to have anyway. |
|
@yarmand I agree for not needing a VM - this is why I said support windows server containers, which I believe does not require Hyper-V (source). As for being complicated, it really wasn't - I got it up and running in a matter of minutes. Of course, in my case, I was using Hyper-V as I'm on Windows 10. I'm all for better Linux kernel emulation, just saying this might be an easier route. I'd like to have real containers on Windows 10 instead of using Hyper-V, though I realize that is an "upstream" concern. Edit: that said, I'm not actually sure, since I haven't tested it, if you can run a Linux container on Windows server containers without hyper-v .... logic suggests no. In which case, full steam ahead on this issue! 👍 Edit 2: Actually, you should be able to run a Windows container with WSL inside windows server containers - over-complicated, yes, I see your point, but it would be better than nothing. Might not be so bad if other distributions were supported in WSL, other than just Ubuntu - but I Haven't looked into this yet. |
|
@aseering Does docker use anything in the kernel other than cgroups, namespaces, chroot, and more socket options for AF_Unix? If those are all that are being used, doesn't docker support come practically for free from support for chroot and systemd? I took a look at some of how docker works, and it seems that unlike some of the other container solutions, it doesn't require specific kernel patches. |
|
@fpqc -- I don't know the full list offhand, but I know it also does a bunch of stuff with the kernel network layer. It creates virtual network devices (related to tap/tun devices, I think?, which as you've said are very low priority right now). It creates a virtual network bridge (same syscalls as WSL's socket implementation is in general not robust enough yet. Docker can run over TCP today; but even in that scenario, which is in theory supported, Docker puts a fair bit of stress on the socket, especially when building new containers (it has a client/server model so sends all filesystem data over the network) and there are still bugs/deadlocks in WSL's socket implementation ( #30 #575 ) that cause it to intermittently hang. And, of course, it prefers and defaults to AF_UNIX, which still needs more functionality as you mentioned. It also does bind-mounts of both directories and files, I believe. Bind-mounts ought to be easy to implement, I think? But I don't think they work yet. WSL would have to implement the requirements for at least one of the storage backends -- one of AUFS, OverlayFS, BtrFS's snapshotting capabilities, or the whole DeviceMapper subsystem plus loopback devices and Also, there's "supports cgroups and namespaces" and then there's "supports cgroups and namespaces" :-) My understanding, which may be incorrect, is that systemd only really requires pretty basic support for both, at least to get it minimally working. Enumerating the available cgroups, setting some values, etc. Docker uses both cgroups and namespaces extensively; I would be surprised if it worked properly without relatively complete support for the network namespace; I don't know offhand about other namespaces. Docker uses cgroups to impose various restrictions on the processes within a container; I don't have a clear picture in my head of exactly how it uses cgroups, but my guess is that basic containers would mostly work with stubbed-out support there, but they would be somewhat flaky and wouldn't support a bunch of Docker's resource-limiting features without more complete support. You're right that Docker doesn't require specific kernel patches. For perspective, though: In the US at least, Red Hat Enterprise Linux is the most popular enterprise Linux solution. And RHEL 6 (or its free counterpart CentOS 6) is the most common version in existing deployments. So there's a huge market pressure to support RHEL 6 -- lots of big companies would be willing to pay someone to make it work. Docker never supported RHEL 6.4 or older because its kernel simply lacked necessary functionality. They worked with Red Hat to backport some network-namespace-related stuff from newer kernels into the CentOS 6.5 and 6.6 kernels, but that effort proved to be buggy and insufficient so they have since dropped support for RHEL 6 entirely. (Though Red Hat will happily sell you Docker support and extra features on RHEL 7 :-) ) Docker doesn't require patches because they're working with, and extending, features that are baked into the core kernel. As I recall, networking was an issue at one point, as was capping physical memory (Linux has supported virtual-memory caps for a long time but I believe physical-memory caps are more recent). Other things too, I'm sure. These days, I think it's filesystem stuff; their OverlayFS doc hints a little bit about the kinds of new kernel functionality that they're using. WSL is keeping the Windows kernel team busy, but the Linux kernel team is busy too :-) |
|
@aseering I have to admit, I wouldn't be very surprised if MS decides to wait until something like Redstone 3 or Redstone 4, after Server 2016 and Windows containers come out, if only because container-mania, if it continues that long, will make it so MS's customers will demand the ability to run both Windows and Linux workloads on a single kernel without any further virtualization. The difference between RHEL6/CentOS6 is that Windows Server 2016 will not be just LTS. RHEL6 and CentOS6 are using basically an LTS kernel forked from the mainline kernel all the way back in 2009, with only security updates backported, which means no cgroups whatsoever. That's like asking MS to backport Windows Containers back to Windows Server 2008R2. Docker doesn't support kernels that are older probably than cgroupsv2. If it supported cgroupsv1 (not sure how old Docker is), compatibility was dropped because cgroupsv1 was deemed unstable and was removed from the Kernel. But yeah, the thing you said about the level of cgroups support necessary for docker, as well as docker taking over Linux's network configuration, means that Docker would be hard to support (based on my reading of its Kernel Option requirements listed on the Gentoo wiki). Thanks for your long and detailed answer though. |
|
@fpqc -- yeah, good points; I agree :-) Also, yeah, RHEL 6 is running a really old kernel :-) I guess that speaks to the point I was trying to make: WSL supports a lot of Linux functionality that was commonly used back in 2009. So far, its support for kernel functionality introduced more recently is much more limited. So it's in some ways comparable to RHEL 6's kernel. Not a perfect analogy, certainly. But if it's hard to backport Windows Containers to Windows Server 2008R2, I would expect by analogy that it would be hard to backport Linux Containers to the initial release of WSL. |
|
@aseering True, but I suspect that since MS has cgroups-like functionality inside of the NT kernel as part of the Windows containers project, they might be able to write a thin layer to implement cgroups, rather than having to emulate everything. |
|
I'm running Docker for Windows 1.13.0 and WSL - having installed docker into WSL (and having all the fail-whale drama), I can however, run "docker -H localhost:2375 run hello-world" and send other commands from WSL into windows native. Cool. What would be useful here, would be able to edit the DOCKER_OPTS (https://docs.docker.com/engine/admin/), set the daemon to point to the Windows version and then start-up. Surely not too much to ask! |
|
Hi @itopiacloud -- unfortunately, What you could do, though, would be something like |
|
I found a workaround here but you need docker for windows running |
|
@alexlopes Hah - I've commented much the same on that thread too.. |
|
i keep running into this issue |
|
I am getting this error on stating So, there is some problem with |
|
yeah, cgroups aren't implemented to my knowledge. Also, I don't know if cgroupsv2 has been fully rolled out in the Linux kernel, and cgroupsv1 is basically dead. This video has some details on why, if you don't want to sift through the LKML stuff: https://www.youtube.com/watch?v=PzpG40WiEfM Basically, the v1 hierarchies made no sense and lots of the controllers would fight against each other for resources (for example, you could give something a ton of memory priority but no disk i/o and it would break virtual memory, etc, or you could give a large amount of cpu with no memory, or you could give a large amount of disk i/o with low memory and you wouldnt have enough memory for buffers to write to disk efficiently or caching reads for efficinet access to frequently used resources), or sometimes didn't do anything at all. The second version is a complete rethink and reimplementation that gets rid of a lot of the implementation showing through and also simplifies the hierarchies and prevents controllers working against each other. Since WSL isn't actually meant for in-production servers, the team might be able to use a simplified or stubbed-out version of cgroups, or maybe somehow cgroupsv2 maps well onto the existing NT kernel infrastructure. I guess we'll see! |
|
Closing this out because as of Creator's Update, docker installs successfully. There are various other issues tracking docker and docker daemon functionality. |
|
Is the Creator's Update GA? |
|
@tnguyen14 - Yes, it was released a few months ago: |
|
@benhillis wait, so we can run linux docker containers on wsl now? |
|
@itaysk - This issue is specifically about docker not installing, which as been fixed. There are other issues tracking various docker pieces not working. |
|
It seems now we should trace for following issue #2291 |
|
@benhillis now i tried install docker-ce according to the official website documentation。 |
|
Can you try manually launching the docker daemon before running this command? |
|
@benhillis yeah |
|
dockerd can run on WSL yes, if you'll try running dockerd you'll see the errors. there are multiple things missing from the kernel in WSL, cgroups is one of them. I think it would be a killer feature for WSL. but sound like it conflicts with Microsoft selling windows docker support as part of windows 10 pro. It's it a bit sad that I need to assume such thing. Can someone from Microsoft end please say it bit more clearly ? what is the direction here ? lots of threads I've seen here around this specific issue. And I believe it's more then technical question. Don't get me wrong, Microsoft are entitled to this money, this task of getting docker to work natively is far from being easy nor cheap. |
|
@fruch cgroups are a feature of the memory manager, and in Linux non-server systems, they are almost entirely used by Systemd. By the way, Windows containers are not available in Win10 Pro. Hyper-V containers are, and the reason why they are restricted to Win10Pro is because Hyper-V is only available on Win10 Pro. |
|
@fpqc thanks, I actually meant hyper-v (I don't have much need yet for windows containers), and I don't really care much how it works under the hood (A big fat lie..) as long it's working fast and reliable, and have the same features as docker on linux system. and I want for free... (could be nice if it would be free, but 99$ extra for win10pro sounds reasonable enough for me, as long it's working from WSL) |
|
This is what I get trying to start |
|
No cgroups support right now. I wonder what would happen if it were for all intents and purposes stubbed out. |
I say go full Law of WSL Github and ask for this. |
|
Dunno if it has been stubbed out but in build 17134 this is what a working dockerd inside WSL shows at launch: |
and others
The text was updated successfully, but these errors were encountered: