Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
Michael H. Warfield wrote: On Mon, 2010-01-25 at 21:50 +0100, Daniel Lezcano wrote: apologies for the length, but how is everyone else handling this? this is the last thing i need to solve before i actually start running all my services on this setup. I was wondering if the kernel shouldn't send a signal to the init's parent when sys_reboot is called. Which still leaves open the question of telling the difference between a halt and a reboot. Well, with the correct information in siginfo, that should do the trick: si_num = SIGINFO ? SIGHUP ? si_code = SI_KERNEL si_int = the cmd passed to the reboot (2) function. -- 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
Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
Michael H. Warfield wrote:
On Mon, 2010-01-25 at 21:50 +0100, Daniel Lezcano wrote:
apologies for the length, but how is everyone else handling this?
this is the last thing i need to solve before i actually start running
all my services on this setup.
I was wondering if the kernel shouldn't send a signal to the init's
parent when sys_reboot is called.
Which still leaves open the question of telling the difference between a
halt and a reboot. My trick of using the final runlevel
in /var/run/utmp ran a foul over a gotcha in the Debian containers that
they seem to default to mounting tmpfs over /var/run and /var/lock so
you loose that information. I had to disable RAMRUN and RAMLOCK
in /etc/default/rcS in the debian images to get around that but I'm not
sure I'm happy doing that. The alternative examining /var/log/wtmp
didn't work out as reliable. OpenVZ has a similar problem and it writes
a reboot file that can be read but that seems inelegant as well. I
don't think anything works if someone does a reboot -f but I need to
test that condition yet.
To also answer the OP's question. Here's what I use. I have a script
that runs periodically in the host. If the number of processes in a
running container is 1, then I check for the runlevel in
${rootfs}/var/run/utmp. If that's ? 0 then it's a halt and I run
lxc-stop. If it's ? 6 then it's a reboot and I stop the container and
then restart it. I run it every 5 minutes or so or manually. It runs
fast and could be run more often. Just sucks polling things like that,
though. That script, lxc-check, is attached.
I trick I just found:
while $(true); do
inotifywait /var/lib/lxc/debian/rootfs/var/run/utmp;
if [ $(wc -l /cgroup/debian/tasks | awk '{ print $1 }') = 1 ]; then
lxc-stop -n debian
fi;
done
This command can stay always there and it will trigger a lxc-stop when
the container remains with 1 process.
No polling and immediate :)
At the first glance, it seems to work well, but of course not compatible
with upstart.
linux-owop:~ # lxc-start -n debian reset; echo
exited ##
SELinux: Could not open policy file =
/etc/selinux/targeted/policy/policy.24:
No such file or directory
INIT: version 2.86 booting
Activating swap...done.
Cleaning up ifupdown
Loading kernel modules...FATAL: Could not load
/lib/modules/2.6.32-mcr-3.18/modu
les.dep: No such file or directory
Checking file systems...fsck 1.41.3 (12-Oct-2008)
done.
Setting kernel variables (/etc/sysctl.conf)...done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Setting up networking
Configuring network interfaces...Internet Systems Consortium DHCP Client
V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth0/d6:c8:78:f7:09:12
Sending on LPF/eth0/d6:c8:78:f7:09:12
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 172.20.0.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 172.20.0.1
bound to 172.20.0.10 -- renewal in 34492 seconds.
done.
INIT: Entering runlevel: 3
Starting OpenBSD Secure Shell server: sshd.
Debian GNU/Linux 5.0 debian console
debian login: root
Last login: Mon Jan 25 23:28:34 UTC 2010 on console
Linux debian 2.6.32-mcr-3.18 #19 Mon Jan 25 11:19:47 CET 2010 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
debian:~# poweroff
Broadcast message from r...@debian (console) (Mon Jan 25 23:32:07 2010):
The system is going down for system halt NOW!
INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal
debian:~# Asking all remaining processes to terminate...done.
Killing all remaining processes...failed.
Deconfiguring network interfaces...There is already a pid file
/var/run/dhclient.eth0.pid with pid 187
removed stale PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth0/d6:c8:78:f7:09:12
Sending on LPF/eth0/d6:c8:78:f7:09:12
Sending on Socket/fallback
DHCPRELEASE on eth0 to 172.20.0.1 port 67
done.
Cleaning up ifupdown
mount: / is busy
Will now halt.
INIT: no more processes left in this runlevel
exited ##
linux-owop:~ #
--
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
Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
Michael H. Warfield wrote: On Mon, 2010-01-25 at 23:39 +0100, Daniel Lezcano wrote: Michael H. Warfield wrote: On Mon, 2010-01-25 at 21:50 +0100, Daniel Lezcano wrote: apologies for the length, but how is everyone else handling this? this is the last thing i need to solve before i actually start running all my services on this setup. I was wondering if the kernel shouldn't send a signal to the init's parent when sys_reboot is called. Which still leaves open the question of telling the difference between a halt and a reboot. Well, with the correct information in siginfo, that should do the trick: si_num = SIGINFO ? SIGHUP ? si_code = SI_KERNEL si_int = the cmd passed to the reboot (2) function. I concur that sounds like a good option. But that's a kernel mod and will require a kernel patch and getting that through the process. Once that's agreed on that's the route to go, we've got to get the containers guys involved and get that pushed through. And is this going to work without any modifications to init itself (per the discussion over on the -devel list wrt modifications to init and the difficulty and pain of pulling teeth). What's the next step? Send a patch with this hack even if it is not the right approach, let's receive some flaming and discuss with containers@/lkml@ about this problem. As I have, one foot in userspace with lxc and another foot in the container kernel development, if we reach a consensus, that should not be a big deal to push upstream a patch, especially if this is a blocker for the container technology. The objective is to have a kernel patch making possible to support the shutdown / halt / reboot / etc ... without modifying the init command and compatible with sysv init and upstart. The patch I propose is to send a signal to the parent process of the pid namespace, in our case it's lxc-start. Handling this signal is quite easy as we have just kill -9 the init process and, in case of a reboot, return to the starting code without exiting lxc-start. -- 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
Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
On Tue, 2010-01-26 at 00:42 +0100, Daniel Lezcano wrote:
I trick I just found:
while $(true); do
inotifywait /var/lib/lxc/debian/rootfs/var/run/utmp;
if [ $(wc -l /cgroup/debian/tasks | awk '{ print $1 }') = 1 ]; then
lxc-stop -n debian
fi;
done
Seems to be a problem with that approach. I'm not seeing anythign
in /var/lib/lxc/${VM}/rootfs any more. Use to with 0.6.4 and earlier
but not now. That seems to have gone away. That might have been a
way to get around that tmpfs problem but it's not there and I have to
resort back to the real rootfs.
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
Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
On Tue, 2010-01-26 at 01:50 +0100, Daniel Lezcano wrote:
Michael H. Warfield wrote:
On Tue, 2010-01-26 at 00:42 +0100, Daniel Lezcano wrote:
I trick I just found:
while $(true); do
inotifywait /var/lib/lxc/debian/rootfs/var/run/utmp;
if [ $(wc -l /cgroup/debian/tasks | awk '{ print $1 }') = 1 ]; then
lxc-stop -n debian
fi;
done
Seems to be a problem with that approach. I'm not seeing anythign
in /var/lib/lxc/${VM}/rootfs any more. Use to with 0.6.4 and earlier
but not now. That seems to have gone away. That might have been a
way to get around that tmpfs problem but it's not there and I have to
resort back to the real rootfs.
With a version 0.6.4 the lxc-debian script write the rootfs in the
/var/lib/lxc/debian/rootfs.
With a version = 0.6.4 the rootfs is created in the current directory.
Note if you have the source code from git, I incremented the version
right before the tag 0.6.5, so you may have a pre-0.6.5 but with the
0.6.4 version information.
Ah! If you look at that lxc-check script I had attached, it tries to
find the rootfs by looking up the config and then, if necessary,
dereferencing through any mount points for that rootfs that may be in
the VM fstab (part of my OpenVZ ve - lxc conversion and compatiblity)
so I guess I've got that covered since I go for the ${ROOTFS}. Try and
keep things as generic as possible.
Thanks for that clarification!
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
Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
On Tue, 2010-01-26 at 01:37 +0100, Daniel Lezcano wrote: Ah, ok didn't know upstart kept using utmp for compatibility. Interesting. Too much depends on that entire utmp.h stuff. Thou shalt NOT break Posix compliance. 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
Re: [Lxc-users] How to make a container init DIE after finishing runlevel 0
On Mon, 2010-01-25 at 20:50 -0500, Michael H. Warfield wrote: Mui Bien! Gracias! Or... I really should have responded... Merci beaucop. Studying Spanish. Haven't had French since high school (and my Russian is real rusty). But I'm trying... Attached. Mike 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 -- 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
