'Unrecognized Input header' on start

[tnolet]

After adding some basic packages to the standard centos image and commiting the result, I always get the error: "Unrecognized input header".
The container starts OK, but it doesn't work anymore when using fleetctl. This is 99% sure because of the non-zero exit code.

core@core-01 ~ $ docker run tnolet/centos
2014/04/20 22:03:19 Unrecognized input header
core@core-01 ~ $ echo $?
1
core@core-01 ~ $ docker ps
CONTAINER ID        IMAGE                  COMMAND             CREATED              STATUS              PORTS               NAMES
01a7013f8295        tnolet/centos:latest   /bin/bash -l        About a minute ago   Up About a minute                       

Additions from the standard centos image are just yum installs of openjdk 1.7, git and tar.

I'm running the latest version on core-os:

Docker version 0.10.0, build dc9c28f

Containers: 24
Images: 29
Storage Driver: btrfs
Execution Driver: native-0.1
Kernel Version: 3.13.10+

Linux core-01 3.13.10+ #2 SMP Wed Apr 16 20:14:42 UTC 2014 x86_64 Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz GenuineIntel GNU/Linux

[vieux]

Can you push your image on the public index ?

[tnolet]

Hi,

The image is hosted at: https://index.docker.io/u/tnolet/centos6/
I use it to run Vert.x inside docker. This works just fine, except for the output error. I first thought it had something to do with how I build the eventual images from my base tnolet/centos6 image by using the following dockerfile. But even in it's bare state (no app downloaded etc.) it returns the error when started. This is a dockerfile I use in conjunction with this image:

# Start and run metricstorm

FROM tnolet/centos6
MAINTAINER Tim Nolet, tnolet@xebia.com
ENV JAVA_HOME /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/
RUN git clone https://github.com/tnolet/metricstorm.git
EXPOSE 80
CMD ["vertx", "run", "metricstorm.rb", "-cp", "metricstorm"]

I'm using fleetctl on core-os to schedule the container, and it exits noting that docker exited with status=1, which is correct of course.

Update: I could easily reproduce this running a core-os instance on EC2.
Apr 20 23:53:20 core-03 systemd[1]: metricstorm.service: control process exited, code=exited status=1

[skolos]

I have same problem. Looks like #2414 is back.

1. docker run -t -i ubuntu bash
2. inside the container: mkdir test and then exit
3. next: docker commit b6d skolos/test
4. finally try to run the image: docker run skolos/test ls and get:

Unrecognized input header

If instead of steps 1 and 2 I do docker run ubuntu mkdir test the step 4 runs without errors.

I pushed the image with the error to skolos/rest

Finally here is the version of docker that I am running:
$ docker version
Client version: 0.10.0
Client API version: 1.10
Go version (client): go1.2.1
Git commit (client): dc9c28f
Server version: 0.10.0
Server API version: 1.10
Git commit (server): dc9c28f
Go version (server): go1.2.1
Last stable version: 0.10.0

[unclejack]

This is a duplicate of #4857.

[andynemzek]

I have the exact same problem as @skolos. I realize there are several issues (namely this one, #4857, #4882) here and I've read through what I could find, but am still confused.

In my scenario I run an ubuntu image with -i -t and make some changes to it interactively. After this I commit the container to create a new image. I then try to run a command in the image like this: docker run image_name command and I get the input header error mentioned above.

If I run the same command with -t, it appears to run fine. So, why do I have to use -t if I want to run a command that's not interactive? Just because I set things up interactively doesn't mean I want to run them interactively...

[tiborvass]

@andynemzek did you test with master?

[andynemzek]

Negative, I am using 0.11.1, build fb99f99. Is this no longer a problem in master? That was the other thing that was unclear to me...#4882 seems to imply that the 'fix' is to simply inform the user that they need to use the -t arg. I'm just wondering why this is a requirement. That is, why am I forced to use -t to run future commands after having built something up interactively?

[rvs]

Running into the very same issue with my ubuntu images; what's the recommendation for a workaround? Different version of docker?

[andynemzek]

@rvs from what I understand, the workaround is to use -t when executing a docker image that's been interactively built :(

[tiborvass]

@andynemzek building an image interactively does not mean you want to run containers interactively. You could build an apache server interactively and then run apache in a container non-interactively, without a TTY. The PR #4882 honors that behavior which is in master.

The solution is to add -t whenever you want a TTY.

[tizzo]

I'm having an issue with this too. I'm building docker images with packer and the resultant images can't be run without -t. Is this a problem with the image's metadata? That seemed to be the conclusion in #4882 but I'm new to docker and I'm trying to sort out what's tripping me up.

I'm running 0.11.1.

[andynemzek]

@tiborvass yea, that's pretty much my use case actually and is why I started asking questions :) I'm not saying you should have to use -t...I'm saying that's the workaround to get past this bug until #4882 is released. Glad to hear #4882 fixes this. Thanks for the help!

[Smana]

I have the same kind of error when i try to execute a command from kubernetes.
kubernetes-sigs/kubespray#131

with docker 1.10.0

[nebirhos]

I get this error with docker 1.10.1 and Gitlab CI multi runner. Weird thing it's it happens only sometimes, running again the same container usually works.

[pdalpra]

Same for me, while running several containers on a Jenkins CI server.

[AaronDMarasco-VSI]

It looks like the 1.10 resurrected version of this bug is #19950.

[thaJeztah]

@Smana @nebirhos @pdalpra a release candidate for 1.10.3, which carries the patch to resolve this is now available for testing https://github.com/docker/docker/releases

[pdalpra]

@thaJeztah Planning the upgrade to 1.10.3-rc2 today on our servers today, I'l keep you posted :)

[thaJeztah]

@pdalpra awesome! I think they're planning to do 1.10.3 GA as well today (San Franscisco time), so a bit short timeframe between RC and GA this time. On that note; did I ask you if you were interested in being added to our "testers" mailinglist? I don't think I've got your contact details, but send me an email at sebastiaan@docker.com and I can add you (and give more details)

[jamshid]

In case others end up here on a Unrecognized input header: search, for me it is happening when using docker 1.11.0-rc3 against swarm running docker 1.10.

$ docker run busybox ip route show
Unrecognized input header: 99
$ docker version
Client:
 Version:      1.11.0-rc3
 API version:  1.23
 Go version:   go1.5.3
 Git commit:   eabf97a
 Built:        Fri Apr  1 23:33:49 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      swarm/1.1.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   7e9c6bd
 Built:        Wed Mar  2 00:15:12 UTC 2016
 OS/Arch:      linux/amd64

I wish new docker clients were backward compatible with older docker versions since I can't upgrade all servers at the same time.
Workaround: keep old docker client binaries and call them explicitly when working with older docker servers.

[thaJeztah]

@jamshid can you open a new issue, so that we can track it separately?

[eungjun-yi]

@jamshid @thaJeztah I have the same problem and posted it as a new issue: #21902