Re: [Lxc-users] Executing a command inside a running container?

2011-05-22 Thread Ulli Horlacher

On Sat 2010-01-30 (14:20), Dominik Schulz wrote:

 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. 

It is not lxc-console which needs authentifcation, but it is login spawned
from the getty on the virtual console.

I found it useless to enter username/password via lxc-console, so I
changed the tty daemon process inside the Ubuntu container to:

  root@vms2:/lxc# cat /lxc/ubuntu/etc/init/tty1.conf 
  # tty1 - root shell 
  #
  # This service opens root shell on tty1

  start on stopped rc RUNLEVEL=[2345]
  stop on runlevel [!2345]

  respawn
  exec /bin/openvt -elfc 1 -- su -l


But you cannot give an command argument to lxc-console. It is for
interactive use only.

Therefore I have written lxc (*) which talks to lxc-cmdd inside the container
which then executes the command. Example:

  root@vms2:/lxc# uname -a
  Linux vms2 2.6.32-31-server #61-Ubuntu SMP Fri Apr 8 19:44:42 UTC 2011 x86_64 
GNU/Linux

  root@vms2:/lxc# lxc -x vmtest8 uname -a
  Linux vmtest8 2.6.32-31-server #61-Ubuntu SMP Fri Apr 8 19:44:42 UTC 2011 
x86_64 GNU/Linux


(*) http://fex.rus.uni-stuttgart.de/download/lxc


-- 
Ullrich Horlacher  Server- und Arbeitsplatzsysteme
Rechenzentrum  E-Mail: horlac...@rus.uni-stuttgart.de
Universitaet Stuttgart Tel:++49-711-685-65868
Allmandring 30 Fax:++49-711-682357
70550 Stuttgart (Germany)  WWW:http://www.rus.uni-stuttgart.de/

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users


Re: [Lxc-users] Executing a command inside a running container?

2011-04-17 Thread Ulli Horlacher
On Sun 2010-01-31 (13:38), Tony Risinger wrote:

 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.  


Ubuntu has upstart instead of the classic init and upstart ignores INT and
PWR signals.

I could do a: ssh container shutdown -h now
But this needs a working networking and a sshd inside the container.

Is there a way to tell upstart to execute a shutdown or at least invoke
/etc/init/control-alt-delete.conf ?



-- 
Ullrich Horlacher  Server- und Arbeitsplatzsysteme
Rechenzentrum  E-Mail: horlac...@rus.uni-stuttgart.de
Universitaet Stuttgart Tel:++49-711-685-65868
Allmandring 30 Fax:++49-711-682357
70550 Stuttgart (Germany)  WWW:http://www.rus.uni-stuttgart.de/

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users


Re: [Lxc-users] Executing a command inside a running container?

2010-01-31 Thread Michael H. Warfield
On Sun, 2010-01-31 at 13:38 -0600, Tony Risinger wrote: 
 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

Ah that's a nice trick.  I'll have to incorporate that into my scripts.

 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

Yeah, that's some of my stuff.  I've since rolled that into an lxc-run
script that does some initialization and then forks off a subprocess
that calls lxc_start as a daemon and then drops into a variation of that
loop.  I'll probably be posting that script in the next day or so.  I'm
almost done cleaning up some of the OpenVZ migration hacks that are
incorporated into it.

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  m...@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!


signature.asc
Description: This is a digitally signed message part
--
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