After years of running LXC and LXD, this is a somewhat recurring topic
which has no good answers, all distros do it differently and the
definition of ready differs even user to user.
So from LXC's point of view, it's best to stay away from this and
instead have users actually check for what they
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
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
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1266808
Title:
No mechanism to wait until a started container is ready and has
finished
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
29 matches
Mail list logo
