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

Fix to "Inject dockerinit at /.dockerinit" #1267

Merged
merged 2 commits into from Aug 5, 2013

Conversation

Projects
None yet
8 participants
@sridatta
Contributor

sridatta commented Jul 22, 2013

This is a modification to pull request #898 by @shykes. It fixes the issue where the TestUser unit test fails when running a command as a non-root user.

The _dockerinit directory was being created with 0700 permissions, which can only be read as root. SysInit could not read the container's rootfs when it dropped to a non-root uid, since _dockerinit is being used as an AUFS branch of the rootfs. This caused all commands to fail when not run as root.

The fix is to set permissions of the _dockerinit directory to 0755, which matches the permissions of the layer directories of all other images.

N.B. if unit tests continue to fail, delete /var/lib/docker/unit-tests and run again. It may contain an old _dockerinit directory, which causes the test runtimes to skip creating it with the right permissions.

Solomon Hykes and others added some commits Jun 14, 2013

@shykes

This comment has been minimized.

Collaborator

shykes commented Jul 23, 2013

Thanks Sridatta! I hadn't had time to get back to that. Very appreciated.

On Mon, Jul 22, 2013 at 3:24 PM, Sridatta Thatipamala <
notifications@github.com> wrote:

This is a modification to pull request 898 by @shykeshttps://github.com/shykes.
It fixes the issue where the TestUser unit test fails when running a
command as a non-root user.

The _dockerinit directory was being created with 0700 permissions, which
can only be read as root. SysInit could not read the container's rootfs
when it dropped to a non-root uid, since _dockerinit is an AUFS branch of
the rootfs. This caused all commands to fail when not run as root.

The fix is to set permissions of the _dockerinit directory to 0755, which

matches the permissions of the layer directories of all other images.

You can merge this Pull Request by running

git pull https://github.com/sridatta/docker new-clean-init

Or view, comment on, or merge it at:

#1267
Commit Summary

  • + Runtime: inject dockerinit at /.dockerinit instead of overwriting
    /sbin/init. This makes it possible to run /sbin/init inside a container.
  • change permissions of initLayer to be readable by non-root users

File Changes

  • M container.gohttps://github.com//pull/1267/files#diff-0(2)
  • M docker/docker.gohttps://github.com//pull/1267/files#diff-1(2)
  • M graph.gohttps://github.com//pull/1267/files#diff-2(33)
  • M image.gohttps://github.com//pull/1267/files#diff-3(14)
  • M lxc_template.gohttps://github.com//pull/1267/files#diff-4(2)
  • M runtime_test.gohttps://github.com//pull/1267/files#diff-5(2)

Patch Links:

@vieux

This comment has been minimized.

Collaborator

vieux commented Jul 23, 2013

LGTM

@ramarnat

This comment has been minimized.

ramarnat commented Jul 24, 2013

New to docker. I have rebuilt docker with these commits. But I am not sure how I actually use the .dockerinit. Do I create the emptyfe in my Dockerfile?

@ramarnat

This comment has been minimized.

ramarnat commented Jul 24, 2013

That was autocorrected! Emptyfe = Empty file

@shykes

This comment has been minimized.

Collaborator

shykes commented Jul 24, 2013

It's completely transparent, you don't need to do anything. The only difference is that "docker run IMG /sbin/init" will work :)

@solomonstre
@getdocker

On Wed, Jul 24, 2013 at 4:11 PM, Rohit Amarnath notifications@github.com
wrote:

New to docker. I have rebuilt docker with these commits. But I am not sure how I actually use the .dockerinit. Do I create the emptyfe in my Dockerfile?

Reply to this email directly or view it on GitHub:
#1267 (comment)

@ramarnat

This comment has been minimized.

ramarnat commented Jul 24, 2013

I thought that was the case. I will try the /sbin/init from docker. What I was trying was install upstart (it's a dependency of another package), on the centos image, but the install fails with an error about /sbin/init

@solomonstre

This comment has been minimized.

solomonstre commented Jul 24, 2013

That sounds like an error that will be fixed with this patch. Let me know if it works!

@solomonstre
@getdocker

On Wed, Jul 24, 2013 at 4:23 PM, Rohit Amarnath notifications@github.com
wrote:

I thought that was the case. I will try the /sbin/init from docker. What I was trying was install upstart (it's a dependency of another package), on the centos image, but the install fails with an error about /sbin/init

Reply to this email directly or view it on GitHub:
#1267 (comment)

@ramarnat

This comment has been minimized.

ramarnat commented Jul 25, 2013

So running /sbin/init gives me:

vagrant@precise64:~$ docker run ramarnat/centos_test /sbin/init
You should not invoke docker-init manually

I think that is the expected behavior, but if I were to run the install that does the upstart install, I still get this error:
error: unpacking of archive failed on file /sbin/init: cpio: rename

The entire run looks like this:
https://gist.github.com/ramarnat/6076444

I believe this is because this is being mounted read-only. Thoughts on a work around?

@sridatta

This comment has been minimized.

Contributor

sridatta commented Jul 25, 2013

Sounds like your build is still bind mounting to /sbin/init. Did you build
using the Makefile or using go build?

@ramarnat

This comment has been minimized.

ramarnat commented Jul 25, 2013

@ramarnat

This comment has been minimized.

ramarnat commented Jul 25, 2013

@sridatta I think you are correct, but if I go into the build container, /go/src, the code has these commits. So I'm not sure what's going on.

@solomonstre

This comment has been minimized.

solomonstre commented Jul 25, 2013

Could you double-check that 'docker -d' is indeed running your new build?
What's the output of 'docker info' and 'docker version'?

Thanks

On Wed, Jul 24, 2013 at 8:44 PM, Rohit Amarnath notifications@github.comwrote:

@sridatta https://github.com/sridatta I think you are correct, but if I
go into the build container, /go/src, the code has these commits. So I'm
not sure what's going on.


Reply to this email directly or view it on GitHubhttps://github.com//pull/1267#issuecomment-21531604
.

@sridatta

This comment has been minimized.

Contributor

sridatta commented Jul 25, 2013

@ramarnat Your shell transcript starts with "vagrant@precise64", which indicates you are running the container from the Vagrant box. When following the "standard development environment", you should test Docker commands inside a docker container by first doing docker run -i -t docker bash.

@ramarnat

This comment has been minimized.

ramarnat commented Jul 25, 2013

@sridatta actually that was the right docker, I had run this command to get the docker binary from the container:

    docker run docker sh -c 'cat $(which docker)' > docker-build && chmod +x docker-build
    mv /usr/bin/docker /usr/bin/docker.orig
    mv ./docker-build /usr/bin/docker

Running docker version gave me:

vagrant@precise64:~/docker$ docker version
Client version: 0.5.0-dev
Server version: 0.5.0
Go version: go1.1

So the issue was apparent: client is the new build, but the server was still running the original build
Restarted the daemon, and viola:
vagrant@precise64:~$ docker version
Client version: 0.5.0-dev
Server version: 0.5.0-dev
Git commit: ??
Go version: go1.1.1

Running the upstart install also succeeds, yay!

Step 1 : FROM centos:6.4
 ---> 539c0211cd76
Step 2 : RUN yum -y install upstart
 ---> Running in f5634579de97
Loaded plugins: fastestmirror
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package upstart.x86_64 0:0.6.5-12.el6 will be updated
---> Package upstart.x86_64 0:0.6.5-12.el6_4.1 will be an update
--> Finished Dependency Resolution
  <    Snip   >
Updated:
  upstart.x86_64 0:0.6.5-12.el6_4.1                                             

Complete!
 ---> 99bcf875fa14
Successfully built 99bcf875fa14

@sridatta @solomonstre @shykes Thanks for walking the n00b thru the issue.

Cheers

@solomonstre

This comment has been minimized.

solomonstre commented Jul 25, 2013

Nice!

Note that if you actually 'docker run 99bcf875fa14 /sbin/init', it should
initiate a "boot" in the container, but it will probably hang somewhere
along the line. I'm not sure why, but I suspect it has something to do with
device auto-detection or something similar. I believe it can be fixed
rather easily with a few configuration tweaks. If you have time to look
into it I would be interested in what you find out!

On Wed, Jul 24, 2013 at 9:53 PM, Rohit Amarnath notifications@github.comwrote:

@sridatta https://github.com/sridatta actually that was the right
docker, I had run this command to get the docker binary from the container:
docker run docker sh -c 'cat $(which docker)' > docker-build && chmod +x
docker-build
mv /usr/bin/docker /usr/bin/docker.orig
mv ./docker-build /usr/bin/docker

Running docker version gave me:

vagrant@precise64:~/docker$ docker version
Client version: 0.5.0-dev
Server version: 0.5.0
Go version: go1.1

So the issue was apparent: client is the new build, but the server was
still running the original build
Restarted the daemon, and viola:
vagrant@precise64:~$ docker version
Client version: 0.5.0-dev
Server version: 0.5.0-dev
Git commit: ??
Go version: go1.1.1

Running the upstart install also succeeds, yay!

Step 1 : FROM centos:6.4
---> 539c0211cd76
Step 2 : RUN yum -y install upstart
---> Running in f5634579de97
Loaded plugins: fastestmirror
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package upstart.x86_64 0:0.6.5-12.el6 will be updated
---> Package upstart.x86_64 0:0.6.5-12.el6_4.1 will be an update
--> Finished Dependency Resolution
< Snip >
Updated:
upstart.x86_64 0:0.6.5-12.el6_4.1

Complete!
---> 99bcf875fa14
Successfully built 99bcf875fa14

Thanks for walking the n00b thru the issue.

Cheers


Reply to this email directly or view it on GitHubhttps://github.com//pull/1267#issuecomment-21533202
.

@ramarnat

This comment has been minimized.

ramarnat commented Jul 25, 2013

It hangs almost right away, is there a way to watch the boot process to see where it's choking?

@creack

This comment has been minimized.

Contributor

creack commented Aug 5, 2013

LGTM

creack added a commit that referenced this pull request Aug 5, 2013

Merge pull request #1267 from sridatta/new-clean-init
* Runtime: Fix to "Inject dockerinit at /.dockerinit"

@creack creack merged commit f6fa353 into moby:master Aug 5, 2013

@pauljm

This comment has been minimized.

pauljm commented Apr 16, 2014

@solomonstre or @ramarnat, have you had any luck getting a container to run /sbin/init? I believe we're seeing the same problem. When starting the container (in a boot2docker VBox VM on OS X in our case), we see dozens of errors of the form

udevd[68]: worker [477] did not accept message -1 (Operation not permitted), kill it

on the host, then a handful of the form

udevd[68]: worker [471] unexpectedly returned with status 0x0009

The container then hangs. @solomonstre, sounds like we may be hitting the issue you described. Our container is CentOS-based.

@pauljm

This comment has been minimized.

pauljm commented Apr 16, 2014

Disabling udev in containers (on centos: rpm -e rpm -q udev --nodeps) seems to work for us. I imagine it wouldn't work for all use cases, but we only run init to make upstart available.

Also, clarifying my comment above, we only run into udev issues when starting more than one container.

@vinmartins

This comment has been minimized.

vinmartins commented Sep 5, 2014

I'm building a custom base image with empty directories where the Host volumes are mounted with run -v [dir_host]: [dir_container] to fill.
Up to this point everything seems to work, but I have problems to launch services at startup with run / sbin / init.
It says #1024 that this is the expected behavior, there is no way to run Upstart in containers. I am testing several alternatives without success. I opted for /usr/share/docker.io/contrib/mkimage-busybox.sh script, adapting to my needs.
I added the boot files but nothing happens. Need to implement some services, plus a terminal. There is still no effective solution to this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment