-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
EPIPE with unix sockets from v4.1.2 #3803
Comments
@bnoordhuis ok, i can try that tonight |
fb7a491 Doesn't touch |
Just leaving a note that I am yet to get to this. |
I can reproduce this with docker 1.9 as well (previously it was with 1.7) |
@bnoordhuis @indutny @Fishrock123 Just bisected. 99943e1 is the commit. Reverting that fixes the problem. This is easy to reproduce if you have docker.
|
@gramakri may I ask you to collect |
For good measure, here's the strace when the commit is reverted. Let me know if you need anything else. |
Oh, I think I know what's happening:
Looks like mysql container is closing it's read side right after reading the request from it. I would say that node should not do any empty write, but after all it seems to be a mistake on other side of the pipe (i.e. mysql or whatever provides this docker pipe). Still let's keep this issue open until I will figure out how to remove that empty write. |
@indutny this is basically a HTTP request over unix sockets (docker provides a REST api over /var/run/docker.sock). Sorry for the misleading with 'mysql', you can ignore that since the test case has nothing to do with mysql (it can be named foobar). There are no containers involved in this test case either other than the fact this REST call creates a container. In short, if I understand you correctly, the docker server/daemon is closing the write part of the connection after reading it's stuff. I thought this was valid behavior to close down one end of the socket (shutdown) but I am no expert :-) |
@gramakri while it is a valid UNIX socket usage, I do not think that it could be valid for HTTP. |
I was thinking more about it and it should be perfectly fine to send a follow up empty TCP packets in case of any kind of HTTP request. I'm going to close it, and open an issue for empty TCP packet, but it is going to be a feature request, not a bug report. Sorry! |
Original commit log for libuv@e900006 follows: thread: add support for affinity (nodejs#3774) Backported thread affinity feature and related dependency commits from master. It will add support for those APIs: uv_cpumask_size, uv_thread_setaffinity, uv_thread_getaffinity. The supported platforms are Linux, Freebsd, and Windows. Empty implementations (returning UV_ENOTSUP) on non-supported platforms (such as OS X and AIX). Original commit log for libuv@64669fd follows: thread: add uv_thread_getcpu() (nodejs#3803) Add uv_thread_getcpu() api to get the cpu number on which the calling thread is running.
I get intermittent EPIPE with the following code starting from v4.1.2. This code works consistently fine with <= 4.1.1.
Test output (this is a continuous shell session):
Note how the request works intermittently for >= 4.1.2. If I run it 10 times, it will fail 8 times. But it consistently works below 4.1.1.
The above example was derived from https://github.com/apocas/docker-modem/blob/master/lib/modem.js#L156 (@apocas). I hit this error consistently with dockerode.
The text was updated successfully, but these errors were encountered: