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

[Daniel Lezcano]

Michael H. Warfield wrote:
> 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.
>   

It's a quick and dirty lines of script. For example, I don't know when 
the init process write to utmp at startup. I guess it already forked a 
process otherwise this script will kill the container when it starts. 
But I suppose it's simple to check the runlevel at this point.

> 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.
>   
Ah, ok  didn't know upstart kept using utmp for compatibility. Interesting.