I didn't look too much into this, but would it be possible to make lxc-
wait check the container's runlevel, and have a new booted state
(unless you want to change the meaning of RUNNING) become true once the
runlevel stops being unknown or N or S?
--
You received this bug notification because
I'd prefer to wait until the system is fully booted (traditional
equivalent: rc2.d scripts are all complete), rather than just that
startup scripts are done (traditional equivalent: rcS.d scripts are all
complete).
It doesn't seem to be that waiting for everything to be started would be
much of
FWIW, I just tried the following:
sudo mknod /tmp/x1
sudo lxc-create -t ubuntu-cloud -n c1
sudo cat /var/lib/lxc/c1/config EOF
lxc.mount.entry = /tmp/x1 x1 none bind,create=file 0 0
EOF
sudo cat /var/lib/lxc/c1/rootfs/etc/init/x.conf EOF
description tell lxc monitor we are ready
author Serge
I want it generic because I want adt-virt-lxc to work with any container
it is given, without having to tell the user to set up a special
container with special stuff in this special way.
Other tools will want this too. I have a simple generic trusty
container that I use to start-ephemeral (or
Quoting Robie Basak (1266...@bugs.launchpad.net):
I want it generic because I want adt-virt-lxc to work with any container
it is given, without having to tell the user to set up a special
container with special stuff in this special way.
Other tools will want this too. I have a simple
In this millenium the concept of finished booting becomes more and
more blurry anyway. We still have something like that with sysvinit if
you do an rc2.d/S99_something, but with upstart/systemd/udev rules this
already isn't accurate.
To use the least common denominator we could have a late rc2.d
On Tue, Jan 28, 2014 at 02:06:30PM -, Serge Hallyn wrote:
Each distro+release guest would need to be updated using its own init
system to inform us when the boot is complete, resulting in
container-specific changes to the rootfs which is something we want
to avoid.
I understand your
Each distro+release guest would need to be updated using its own init
system to inform us when the boot is complete
LXC could provide a default implementation (like the above wait until
runlevel switches to 2 and then notify the caller), and then templates
could optionally provide a more refined
Speaking as the upstream for LXC and package maintainer, the only way I
consider to be acceptable for this is the one Serge and I described by
adding a new socket owned by LXC which allows for a simple text based
communication between the container and its host. This protocol would
allow state
I just got hinted at lxc-attach. With that, clients like adt-virt-lxc
can implement their own polling/waiting loop to wait until the runlevel
switches away from unknown/S, which is a lot better (and more generic)
than the current hackery that it's doing. I captured that in bug
1273725.
--
You
This was discussed a few times upstream.
The suggested implementation is to have lxc-start create and bind /dev/lxc in
the container as a standard unix socket.
A simple text based protocol would then be built on top of this including
support for switching to a new ready state.
The idea is that
Thanks. What would listen or own the other end of the socket?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1266808
Title:
No mechanism to wait until a started container is ready and
One possibility,
an upstart job could write to /dev/lxc in the container.
lxc-start would listen to the other end on the host, and update
the container state to USERSPACE_RUNNING or somesuch.
Then lxc-ls would show USERSPACE_RUNNING instead of RUNNING.
--
You received this bug notification
The listening end would be lxc-start, the other end would be whatever is
appropriate.
In Ubuntu this could be an upstart job, on Debian a sysvinit script, ...
There wouldn't be a need for a persistent connection, the socket would just be
there to send messages from the container to the host, so
14 matches
Mail list logo
