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