Child process + pipe tests now failing in Docker

[rvagg]

I've just noticed this, having installed Docker 1.3.2 and running the containers locally, I get EACCES type failures with about 5 of the tests. They all seem to be about child processes and pipes and are related to Docker's new security model. If you run with --privileged then it's fine but that's not desirable for us. It's not a capabilities-related thing because --cap-add=all doesn't make a difference.

For test/simple/test-cluster-http-pipe.js at least (the one I've been mainly focusing on), I've narrowed it down to a read() on the pipe file descriptor on the child in libuv, the connect() is fine, it's only when you start reading that you get the EACCES. My instinct here is to blame Docker, but it's possible that libuv, or even Node, are doing something wrong. The error is as if we're trying to read from protected /dev/ nodes but I'm pretty sure we're note going anywhere near them. No matter where the pipe is put (can be changed with the NODE_COMMON_PIPE env var) it still happens, I've tried /opt/iojs/test.pipe, /tmp/test.pipe, /home/iojs/test.pipe and others to no avail.

If anyone else has a clue or time to chase this down it's be greatly appreciated because this is a big blocker now to getting tests happening on pull requests. I don't even know where to escalate this bug to at the moment or even if it's just isolated to my machine!

[bnoordhuis]

I can look into it but does that entail installing docker locally?

[rvagg]

Either that, or tomorrow I can see if I can replicate it on one of the container build servers and give you access there.

[bnoordhuis]

Yes please, if it's not too much work.

[rvagg]

Couldn't replicate on the main container build machine and decided that the only difference to my local machine is Ubuntu 14.04 vs 14.10 so I've set up a 14.10 box just to test this and ta da, there's the problem.

That means this isn't a blocker issue to getting container builds going against all PRs since we'll probably be on 14.04 for a while, but it does mean there's potentially a problem with newer kernels (or something in that space) that could have broader impact for Node and/or libuv. It will also be a problem for anybody else not on LTS using these containers for themselves locally.

@bnoordhuis I've put your keys on the machine: root@104.236.161.92

Run like this:

cd io.js
docker run -a stdin -a stdout -a stdin -t --rm -v `pwd`:/opt/iojs/ iojs/build:iojs-ubuntu-trusty

To get into the container to run stuff manually within there do:

docker run -t -i --rm -v `pwd`:/opt/iojs/ -w /opt/iojs/ iojs/build:iojs-ubuntu-trusty /bin/bash

You can then run a manual build and test and whatever else you like (including installing stuff with apt-get). Be aware that you'll be root in that last situation but it's running as iojs inside the container in the normal run. It doesn't seem to matter which uid is used during the run though.

If you do a docker run --privileged with either of the above then you'll find it'll work fine, it's unprivileged mode that's the problem.

For reference, and for anybody else looking at this and interested in replicating it for themselves, here's the list of commands for a fresh 14.10 as root:

apt-get install git -y
curl http://get.docker.io | bash -
git clone https://github.com/iojs/io.js.git && cd io.js && git checkout v0.12
adduser iojs --disabled-password --gecos iojs
chown iojs.iojs -R .
docker run -a stdin -a stdout -a stdin -t --rm -v `pwd`:/opt/iojs/ iojs/build:iojs-ubuntu-trusty

[rvagg]

Also, the CMD at the bottom of this is what's run when you don't provide a command (like /bin/bash).

[bnoordhuis]

Haven't forgotten about this. Assigning to myself.

[bnoordhuis]

I think this issue has gone stale. Closing, holler if it's still relevant.