Space in new no_proxy env var breaking old containers?

Expected behavior

It should be possible to run the selenium docker containers that have worked with previous versions of docker.

Actual behavior

These containers fail on startup, logging out:

Waiting xvfb...
-bash: 169.254/16: No such file or directory
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...
Waiting xvfb...

This seems to be caused by:

  • how these container images handle environment variables (spaces in values are not escaped)
  • an apparent new environment variable that seems to have appeared some time between Docker for Mac beta 9 and 13: no_proxy=*.local, 169.254/16. The space in the variable’s value is interacting badly.

As far as I can tell, if going by the wget definition of no_proxy, there should be no spaces in this environment variable - it’s described as comma separated but makes no mention of whitespace as a separator.

Information

Pinata diagnose output:

OS X: version 10.11.6 (build: 15G7b)
Docker.app: version v1.11.1-beta13.1
Running diagnostic tests:
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      slirp
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x
Docker logs are being collected into /tmp/20160530-080322.tar.gz
Most specific failure is: No error was detected
Your unique id is: A64F928A-9028-4BD0-8EFC-D7A9820A13A5
Please quote this in all correspondence.

Steps to reproduce the behavior

  1. WIth Docker for Mac, run docker run -P selenium/standalone-chrome-debug:2.52.0. Observe that the container logs out the error indicated above, and exits with exit code 127.

Additionally:

With Docker for Mac:

$ docker run selenium/standalone-chrome-debug:2.52.0 env

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=0d98e7c76683
no_proxy=*.local, 169.254/16
DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true
TZ=US/Pacific
SCREEN_WIDTH=1360
SCREEN_HEIGHT=1020
SCREEN_DEPTH=24
DISPLAY=:99.0
CHROME_DRIVER_VERSION=2.20
LANGUAGE=en_US.UTF-8
LANG=en_US.UTF-8
HOME=/root

Notice that the no_proxy environment variable is present and contains a space.

Immediately afterwards, in the same shell with Docker Machine:

$ eval (docker-machine env default)    # fish shell syntax
$ docker run selenium/standalone-chrome-debug:2.52.0 env

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=4ef716c51041
DEBIAN_FRONTEND=noninteractive
DEBCONF_NONINTERACTIVE_SEEN=true
TZ=US/Pacific
SCREEN_WIDTH=1360
SCREEN_HEIGHT=1020
SCREEN_DEPTH=24
DISPLAY=:99.0
CHROME_DRIVER_VERSION=2.20
LANGUAGE=en_US.UTF-8
LANG=en_US.UTF-8
HOME=/root

FWIW no_proxy isn’t set in my Mac environment!

Thanks for the report. I’ve fixed this in master and hopefully this should make it in to a release soon - watch the changelog for (#3514)! In the meantime, you can override the no_proxy variable by adding it yourself in docker run -e no_proxy=""
The value you are seeing is picked up from OSX as it seems to be added automatically to some connections. We had a bug in Beta 13 that caused this value to get passed through to Docker for Mac even if you hadn’t specified a HTTP Proxy. This was fixed in Beta 13.1. If you are running Beta 13.1, a reset to factory defaults may remove the bad state for the no_proxy variable.

Awesome, thank you! I’d noticed that it was possible to forcibly override
it, but it’s good to know this will be resolved. I’ll look out for the fix!