Docker Community Forums

Share and learn in the Docker community.

Space in new no_proxy env var breaking old containers?

beta

(Richard North) #1

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!


Need to specify proxy settings
(Dave Tucker) #2

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.


(Richard North) #3

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!