[Lxc-users] How to make a container init DIE after finishing runlevel 0

[Michael H. Warfield]

On Tue, 2010-01-26 at 00:42 +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.  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

Oh I LIKE THAT!

Just a couple of comments...

1) Still have the problem with the Debian default of mounting tmpfs
on /var/run.

2) Probably still need some sort of deadman's switch in case things die
and didn't update utmp.

3) That "if" check is overly complicated.  You don't really need the
awk.  (nit => pick)

4) Still need to separate halt and reboot.  If utmp is valid for
detecting changes then utmp is valid for doing a runlevel query and we
can tee off from that.

But I like it.  I can incorporate that into my start-up wrapper in a
heartbeat.

> 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.

Why isn't it compatible with upstart?  I thought utmp was being
maintained properly even with upstart.  I know upstart doesn't have the
same concept of runlevels and maintains them purely for "compatibility"
but I thought the whole utmp/wtmp was part of that.  Wouldn't this also
work equally well with .../var/log/wtmp instead (other than the fact
that you're going to wake up on every damn wtmp record)?  I'll have to
test.

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/20100125/48b80527/attachment.pgp>