[Lxc-users] Failed to start multiple containers asynchronously.
Hello all, I am trying to create 3 containers and starting 3 containers. I wrote a c program to create 3 containers and different c program to start 3 containers. As i wann to start all containers async, so forked and execl, so that all are different process. It started the first container,but when second containers starts it asks for login:: and passwd:: i gave both but still control remains on first terminal and something strange happen for third terminal. It gives error saying lxc-start: failed to set new terminal settings lxc-start: failed to create console lxc-start: failed to initialize the containe Y is it so? I am using different conf file for each container. The only thing i changed is lxc.tty number. What might be changes in conf file to set new terminal settings. Please help me out ASAP. Regards, Nishant -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Failed to start multiple containers asynchronously.
Are you daemonizing the containers (with lxc-start -d) ? That seems to be the most useful for my when I spin up dozens of containers... I set the lxc.console variable via a --define lxc.console=/var/log/lxc/$container on when I run lxc-start. This seems to work fine. I'm not sure what is all in lxc-create (assuming you are calling these scripts from a .c) but I'm not sure how safe that is to run multiple copies simultaneously (the debootstrap in particular), but maybe it will just work? - mdf On Tue, Sep 6, 2011 at 11:38 AM, nishant mungse nishantmun...@gmail.com wrote: Hello all, I am trying to create 3 containers and starting 3 containers. I wrote a c program to create 3 containers and different c program to start 3 containers. As i wann to start all containers async, so forked and execl, so that all are different process. It started the first container,but when second containers starts it asks for login:: and passwd:: i gave both but still control remains on first terminal and something strange happen for third terminal. It gives error saying lxc-start: failed to set new terminal settings lxc-start: failed to create console lxc-start: failed to initialize the containe Y is it so? I am using different conf file for each container. The only thing i changed is lxc.tty number. What might be changes in conf file to set new terminal settings. Please help me out ASAP. Regards, Nishant -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- -- Matthew Franz mdfr...@gmail.com -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] stopping a container
On 9/5/2011 12:34 PM, Michael H. Warfield wrote: On Mon, 2011-09-05 at 09:24 +0200, Papp Tamas wrote: On 09/05/2011 08:38 AM, Jäkel, Guido wrote: What is the right way to stop a container? Dear Papp, Like with the thread paradigm in computing langugages, the right way is that the thread decides to stop. Therefore your container have to leave. Depending on your Linxus flavor inside the container, you e.g. may send a signal to it's init process to proper shut down. This mechanism is historical intended to be used by an USV poser supply. In the moment, I'm using an old-style sytem v init and I may just send a SIGINT to reboot and a SIGPWR to halt it (must be enabled in the inittab). Another (planned) way is to use lxc-execute, but this is still not working. Ulli Hornbacher therefore wrote it's own workaround: A little daemon executes all command pushed in by a command running at the host -- disregarding to all aspects of security. If you're running a sshd inside the container -- and in the most case you will I think -- you may use this (with a deposited key) to directly send commands to it. hi, I don't like the ssh way. I think, halting a container automatically through an ssh connection is a joke, wich should not be used in any way. Another way that I have used is to send the init process a kill signal. I think it was the power fail sig but that should do it. That definitely worked with the sysv init but I see to recall I had some problem with upstart (and systemd won't currently run in a container anyways - so you can forget that pig). That's not another way. That's exactly the way already stated first above. -- bkw -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] stopping a container
On Tue, 2011-09-06 at 17:34 -0400, Brian K. White wrote: On 9/5/2011 12:34 PM, Michael H. Warfield wrote: On Mon, 2011-09-05 at 09:24 +0200, Papp Tamas wrote: On 09/05/2011 08:38 AM, Jäkel, Guido wrote: What is the right way to stop a container? Dear Papp, Like with the thread paradigm in computing langugages, the right way is that the thread decides to stop. Therefore your container have to leave. Depending on your Linxus flavor inside the container, you e.g. may send a signal to it's init process to proper shut down. This mechanism is historical intended to be used by an USV poser supply. In the moment, I'm using an old-style sytem v init and I may just send a SIGINT to reboot and a SIGPWR to halt it (must be enabled in the inittab). Another (planned) way is to use lxc-execute, but this is still not working. Ulli Hornbacher therefore wrote it's own workaround: A little daemon executes all command pushed in by a command running at the host -- disregarding to all aspects of security. If you're running a sshd inside the container -- and in the most case you will I think -- you may use this (with a deposited key) to directly send commands to it. hi, I don't like the ssh way. I think, halting a container automatically through an ssh connection is a joke, wich should not be used in any way. Another way that I have used is to send the init process a kill signal. I think it was the power fail sig but that should do it. That definitely worked with the sysv init but I see to recall I had some problem with upstart (and systemd won't currently run in a container anyways - so you can forget that pig). That's not another way. That's exactly the way already stated first above. Oh, yeah, guess it's better I read up and read the entire quoted thread and not stop at the comment about ssh. :-P My bad. -- bkw Regards, 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 -- Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] Problem with lxc-attach on Linux v3.1.0
Hi, I have been facing problems getting lxc (more specifically, lxc-attach) to work on Linux v3.1.0-rc4. When I run lxc-attach, I get the following error: $ lxc-attach -n foo -- /bin/bash lxc-attach: No such file or directory - failed to open '/proc/821/ns/pid' lxc-attach: failed to enter the namespace More info: $ uname -a Linux nf-build2 3.1.0-rc4-with-cfs-dctcp #3 SMP Mon Sep 5 23:56:47 PDT 2011 x86_64 GNU/Linux I had enabled namespace config while building the kernel: CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y lxc-checkconfig doesn't seem to show any problems: lxc-checkconfig Kernel config /proc/config.gz not found, looking in other places... Found kernel config file /boot/config-3.1.0-rc4-with-cfs-dctcp --- Namespaces --- Namespaces: enabled Utsname namespace: enabled Ipc namespace: enabled Pid namespace: enabled User namespace: enabled Network namespace: enabled Multiple /dev/pts instances: enabled --- Control groups --- Cgroup: enabled Cgroup clone_children flag: enabled Cgroup device: enabled Cgroup sched: enabled Cgroup cpu account: enabled Cgroup memory controller: enabled Cgroup cpuset: enabled --- Misc --- Veth pair device: enabled Macvlan: enabled Vlan: enabled File capabilities: enabled I'm using the latest version of lxc from the git repo: commit f7b98d38f042c403114fd07187dfe7daed44bdda I spawn a container using the following command: $ lxc-execute -n foo -f /etc/mn/host.conf -- /bin/bash It seems to be working perfectly alright. $ cat /etc/mn/host.conf lxc.utsname = mnhost lxc.network.type = empty lxc.network.flags = up $ lxc-ls foo I picked a random pid in the system and ran: $ ls /proc/32157/ns/ ipc net uts (pid is not present in the directory.) According to http://kernelnewbies.org/Linux_3.0#head-69fb31d5d1d284f3a95e56d0ec43a2b23c30c4f3 setns() is enabled by default from Linux v3.0. So, I did not apply any specific patches for setns. Am I doing something wrong? I'd appreciate any help. Thanks, Nikhil -- Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
