[Lxc-users] Executing a command inside a running container?
Michael H. Warfield
mhw at WittsEnd.com
Wed Feb 3 14:36:51 UTC 2010
Hey hey...
On Sun, 2010-01-31 at 13:38 -0600, Tony Risinger wrote:
> On Sat, Jan 30, 2010 at 12:11 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > On Sat, 2010-01-30 at 14:20 +0100, Dominik Schulz wrote:
> >> Hi,
> >>
> >> I'm fairly new to LXC and I am looking for a way to execute a command inside a
> >> running container (a full blow one with its own rootfs and full isolation).
> >> lxc-execute doesn't seem to do the trick and lxc-console requires credential
> >> to login. I'm looking for a way to execute command w/o having to login via ssh
> >> or the lxc-console, so I can execute command directly inside the containers to
> >> shut them down properly.
> >
> > This is being worked on and looked at now through the use of some sort
> > of daemon in the running container but is not currently possible. More
> > over, cgroups in the kernel does not currently support joining an active
> > cgroup, and may never support it, so it would have to be done through
> > the mediation of some sort of daemon in the running container and
> > communicating with the host. There's been discussion on the -devel list
> > over the optimal way to do it and there are some patches running around
> > but AFAICT nothing has really been committed or committed to at this
> > time.
> if your using the standard init program, and you are only trying to
> control stutdown/reboot, i use something like this in my container
> inittab:
> p6::ctrlaltdel:/sbin/init 6
> p0::powerfail:/sbin/init 0
A lot of systems, like Fedora, are now using upstart. So, on fedora,
you've got /etc/event.d/control-alt-delete for the ctrlaltdel condition.
By default it's set to:
/sbin/shutdown -r now "Control-Alt-Delete pressed"
Not sure where it's handling powerfail.
Some of my older systems have this in inittab:
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
That's a 2 minute delay in the shutdown. Yeah, I could modify those
lines to be the init commands, but that won't work in the upstart
systems.
My Ubuntu 9.04 container has this for powerfail related stuff:
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
Ok... Not sure about that. At least the ctrlaltdel looks good.
> ctrlaltdel responds to a SIGINT, and powerfail responds to SIGPWR.
> this lets you send a:
> kill -INT <init pid>
> to reboot, and:
> kill -PWR <init pid>
Since this is all being run in the host environment, anyways... Another
trick, which I'm now incorporating into the monitory code described
below, is to set a file /var/lib/lxc/{VM}/halt_on_reboot if I want to
halt the container. THEN hit it with the -INT signal, which causes it
to start an immediate orderly shut down in either default case. We can
then take advantage of the hang at the end and the monitor code below
(or some variation there of) to decide to halt or reboot. Modify the
reboot case in the code below to include an if check on that file. If
it's there, remove the file but don't restart the container after
stopping it.
One gotcha in this is that we don't readily know the host pid of the
init process in the container. My startup scripts are now snarfing that
down right after starting the container and pawing through the tasks
file and /proc/{pid}/cmdline looking for init. That pid gets dumped
in /var/lib/lxc/{VM}/pid where we can reference it later. It really
shouldn't change over the life of the container.
Now I can have an lxc-shutdown command that snatches that pid, sets that
file, and issues the -INT and it should force the container into an
orderly shutdown. I like this.
> to shutdown. you will also need the help of a "monitor" process to
> overcome the fact that the init process will hang around, even though
> all other processes in the container are dead. an earlier thread
> detailed a nice trick using inotifywait and the utmp file in the
> container, see this thread for ideas:
>
> http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg00040.html
>
> specifically this post on:
>
> http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg00049.html
>
> you basically monitor the utmp file in the container for a change,
> then run "runlevel <utmp file>" to get the runlevel in the container,
> and act appropriately. here is an excerpt from my scripts (originally
> based off one provided in the previous thread), it has variables
> specific to my setup but it's fairly self explanatory:
>
> while true; do
> # time of 5 minutes on it JUST IN CASE...
> vps_utmp=${VPS_DOM}/${vps}/rootfs/var/run/utmp
> inotifywait -qqt 300 ${vps_utmp}
> if [ $(wc -l < ${VPS_VAR}/cgroup/${vps}/tasks) -eq 1 ]; then
>
> runlevel="$(runlevel ${vps_utmp})"
>
> case $runlevel in
> N*)
> # nothing for new boot state
> ;;
> ??0)
> # halted... kill vps.
> lxc-stop -n "${vps}"
> break
> ;;
> ??6)
> # rebooting... kill vps and start again...
> lxc-stop -n ${vps}
> lxc-wait -n ${vps} -s STOPPED
> lxc-start -d -n ${vps} -o ${VPS_LOG}/${vps}.log
> # loop again.
> ;;
> *)
> # make sure vps is still running
> state="$(lxc-info -n "${vps}" | sed -e 's/.* is //')"
> [ "$state" = "RUNNING" ] || break
> ;;
> esac
> fi
> done
>
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20100203/4f0c504f/attachment.pgp>
More information about the lxc-users
mailing list