On Sat, Jan 30, 2010 at 12:11 PM, Michael H. Warfield <m...@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 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> 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 ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users