Run /sbin/init

[mojodna]

This would allow docker to be used to manage containers in full-on instance mode vs. single-use containers.

[jpetazzo]

Docker currently overrides /sbin/init, but you can try the following hack:

• copy /sbin/init to /sbin/init.real
• start /sbin/init.real
  You will probably hit weird things since the init system will try to setup things that it really shouldn't mess up with (like network interfaces and filesystems) but that would be a good starting point.

[shykes]

Totally agree, this would be very useful and there is nothing in Docker's design preventing it.

Currently this will not work because of the following implementation detail: when starting a new container, docker mint-bounds itself as /sbin/init inside the container, hiding the real /sbin/init and in the proces smaking it unavailable for execution.

Once docker-as-init has been executed, the binary can be safely unmounted, un-hiding the real /sbin/init and making it available for execution. The problem is that unmounting must be done from outside the container, which requires cross-namespace synchronization between docker-as-init and dockerd. This can be implemented over a unix socket for example.

[sa2ajj]

(I'm not sure if it's totally relevant)

lxc comes with templates for various distributions, and those templates do heavy hacking of the freshly installed systems to make them runnable in a container (e.g. Debian template and Ubuntu template)

So if the filesystem is not "adjusted", users might run into other kind of problems...

[vsekhar]

Bringing up an entire system is a use case better served by virtualization. I'm not saying it should be impossible to do with docker, just that it's not the core value prop. Docker seems to be best at process-level isolation, not machine-level. I think encouraging developers to think this way is helpful, and adding complexity/fragility to support full instances seems like a poor tradeoff.

lxc is mostly the same and the hacks needed in their full-system templates are evidence of that.

[sa2ajj]

@vsekhar, I agree.

[shykes]

I agree also. The fix I propose is the right thing to do anyway - the less
side-effects on the guest filesystem, the better. If further changes are
necessary and those changes deviate from Docker's core value prop, we might
not implement them. At this time I'm not aware of any extra changes needed
though.

On Wed, Mar 27, 2013 at 5:21 PM, Mikhail Sobolev
notifications@github.comwrote:

@vsekhar https://github.com/vsekhar, I agree.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-15561614
.

[wereHamster]

Docker overwrites /sbin/init inside the container for three reasons: 1) set the default gateway route, 2) change the user and 3) clean up container from the environment. 1) can be solved by setting lxc.network.ipv4.gateway in the lxc config file, 2) could be left to the user run command (there are chpst, sudo, sysv init scripts, upstart, systemd can do it as well) and 3) what's the reason for that?

[jpetazzo]

1. lxc.network.ipv4.gateway doesn't work with lxc userland tools 0.7, that's why we implemented it; we need to make sure that it works with the tools provided with 12.04.
2. Setting the user from docker itself allows to run unprivileged processes without relying on something specific in the container (which in some cases is a nice feature)
3. Not sure about that one!

I don't know if we are ready to drop the /sbin/init override yet, but it might become an option switch.

[shykes]

I feel like we could solve a big part of the problem simply by mounting docker as /sbin/docker-init instead of /sbin/init. Not perfect but should be good enough.
I know of at least one person who gave up on using docker in favor of a home-made script which did exactly that.

Does anybody oppose this? Any negative side-effects I'm not thinking of?

[jpetazzo]

Might work, but remember that you need to create /sbin/docker-init then.
A good candidate for injection (that would almost always be there, and
could be created harmlessly if it's not) is /bin/true.

[shykes]

Couldn't we just create /sbin/docker-init? Especially if we're going to
have logic to create /bin/true if it doesn't exist anyway.

On Tue, May 28, 2013 at 6:15 PM, Jérôme Petazzoni
notifications@github.comwrote:

Might work, but remember that you need to create /sbin/docker-init then.
A good candidate for injection (that would almost always be there, and
could be created harmlessly if it's not) is /bin/true.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-18590503
.

[jpetazzo]

That works too. Initially the point of bind-mounting init and resolv.conf
(vs. just copying) was to avoid modifying the existing image. Depends if
that's still a priority or not.

[shykes]

Should be simple enough to scope the bind-mount with a touch/rm in case it
doesn't exist, to cover all cases.

On Tue, May 28, 2013 at 6:31 PM, Jérôme Petazzoni
notifications@github.comwrote:

That works too. Initially the point of bind-mounting init and resolv.conf
(vs. just copying) was to avoid modifying the existing image. Depends if
that's still a priority or not.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-18590992
.

[tianon]

I'm not terribly well versed in the issues involved here, but had an idea I wanted to share in case it's useful. What if you check for the existence of /sbin/docker-init first, and if it is there, you use that (so that images prepared specifically with docker in mind can include it and get "upgraded" docker functionality, if you will), but if it isn't, you use /sbin/init (so images that aren't necessarily prepared with docker in mind still work properly).

Again, I'm not well versed in the issues, or have much opinion either way, but it was a thought I had so I figured I'd share in case I'm thinking of something useful (but might just be more complex than what is wanted).

[shykes]

Hey Tianon, what you're describing is indeed very useful, and you can
already do it by setting a default command in the container's metadata.
This way the container author doesn't need to create a specially named file

• you can name it whatever you like and tell docker to run it by default.

One thing thing this doesn't allow is telling docker to execute an "entry
point" command every time the container is run, regardless of the command
specified by the user. That could be an interesting addition.

In any case, those 2 topics are different from what we're discussing -
specifically the ability for the user to type "docker run CONTAINER
/sbin/init" without having docker blow up :)

On Tue, May 28, 2013 at 7:59 PM, Tianon Gravi notifications@github.comwrote:

I'm not terribly well versed in the issues involved here, but had an idea
I wanted to share in case it's useful. What if you check for the existence
of /sbin/docker-init first, and if it is there, you use that (so that
images prepared specifically with docker in mind can include it and get
"upgraded" docker functionality, if you will), but if it isn't, you use
/sbin/init (so images that aren't necessarily prepared with docker in mind
still work properly).

Again, I'm not well versed in the issues, or have much opinion either way,
but it was a thought I had so I figured I'd share in case I'm thinking of
something useful (but might just be more complex than what is wanted).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/223#issuecomment-18593352
.

[tianon]

Ah, that makes much more sense. Thanks for clearing that up! :)

[shykes]

Hey guys, there's a pull request pending to make this possible: #898.

It looks like the base images will need some tweaking to boot properly (booting seems to hang on udev-related things for both ubuntu and centos), but I don't expect it to be too hard.

[shykes]

This has been merged into master, and is scheduled for the 0.6 stable release (target is August 21)

[esamattis]

Ok, this should be in the release now. How do I in practice start the full container in Docker?

I've also posted this on Stackoverflow http://stackoverflow.com/questions/19332662/start-full-container-in-docker

[shykes]

@epeli if you want to start in "machine mode" you can 'docker run /sbin/init'

[chenyf]

hi, @shykes , I start container with :
docker run -d ubuntu:12.04 /sbin/init
This start a container, but how can I login into this container or attach this container?

[tianon]

You'd have to set the root password and install openssh-server. You probably want to use a Dockerfile or docker run bash then docker commit to get the image setup the way you want/need it before you run /sbin/init.

[chenyf]

HI, @tianon ,
Now I try following steps:
1). docker run -i -t ubuntu:12.04 /bin/bash
2). inside container:

dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl

install openssh-server inside it;

cd /etc/init
mv ssh.conf ssh.conf.bak

after these steps, I can start ssh server with both " service ssh start" or "/etc/init.d/ssh start"

3). commit the image
4). start a container with this new image and '/sbin/init'
docker run -d xxxxx /sbin/init

5).
ps auxf

I can't find ssh server inside container.

[chenyf]

[chenyf]

above is the screen snapshot, you can find /sbin/init inside container 8936xxxx

[chenyf]

docker version is 0.6.6

[blalor]

docker run $IMAGE /sbin/init works perfectly. Thank you!

[chenyf]

Hi, @blalor Could you give a detail step about how to use /sbin/init ? thanks!

[blalor]

@chenyf I'm not sure what you're looking for. I'm using the centos base image so life is apparently easier than dealing with ubuntu.

Dockerfile:

FROM centos
RUN yum install -y openssh-server
RUN yum install -y passwd
RUN echo d0cker | passwd --stdin root

## https://github.com/dotcloud/docker/issues/1240#issuecomment-21807183
RUN echo "NETWORKING=yes" > /etc/sysconfig/network

## http://gaijin-nippon.blogspot.com/2013/07/audit-on-lxc-host.html
RUN sed -i -e '/pam_loginuid\.so/ d' /etc/pam.d/sshd

EXPOSE 22
CMD /sbin/init

Run it: docker run -d -P $IMAGE
Find ssh port: docker port $CONTAINER 22
Connect: ssh -p $PORT root@localhost

[kiorky]

you may have a look to our ubuntu based containers
(https://github.com/makinacorpus/vms/tree/master/docker)
You can have also a look to this entry point for a bunch of bugs: #2276

[benbooth493]

I'm looking to running squeeze inside a container as a full-blown vps using the tricks above, but I'm having no success.
Can anyone help?