[lxc-devel] [PATCH 1/3] lxc-shutdown: switch from script to program using api.

Brent Tubbs brent.tubbs at yougov.com
Fri May 17 21:02:22 UTC 2013


+1 to Christian's suggestions.  I run LXC containers under Supervisor,
which provides per-program config options for 'stopsignal' and
'stopwaitsecs' that would map really well to what he's proposed.

On 5/17/13 1:55 PM, "Christian Seiler" <christian at iwakd.de> wrote:

>Hi there,
>
>> So my suggestion is basically to:
>>  - Kill lxc-shutdown
>>  - Change lxc-stop so that:
>>    * Default behaviour is to call shutdown(), wait 15s for STOPPED, if
>> not STOPPED, print a message to the user and call stop()
>>    * We have a -r option to reboot the container (with proper check that
>> the container indeed rebooted within the next 15s)
>>    * We have a -s option to shutdown the container without the automatic
>> fallback to stop()
>>    * Add a -k option allowing a user to just kill a container
>> (equivalent to old lxc-stop, no shutdown() call and no delay).
>>
>> We'd therefore end up with a single binary which does shutdown, stop and
>> reboot, properly checks that the actions are carried out and supports
>> timing out and fallback to kill.
>
>I would like to add that there currently is a setting lxc.stopsignal,
>which overrides 0.9's lxc-stop, but not lxc-shutdown.
>
>A few ideas on how to handle this:
>
> - Create 2 new signals,
>     lxc.signal.halt    (halt container, default: see below)
>     lxc.signal.reboot  (reboot container, default: SIGINT)
>     lxc.signal.kill    (kill container, default: SIGKILL)
> - deprecate lxc.signal.stop (i.e. issue warning if it's used) but
>   make it an initial alias for lxc.signal.halt
> - default for lxc.signal.halt:
>     - container started by lxc-start: SIGPWR
>        (templates should probably adjust that if necessary)
>     - container started by lxc-execute: SIGTERM
>
>> The 15s timeout would be over-ridable through -t, 15s is a guess as to
>> how long users would be ready to wait for a container to die assuming
>> some complex processes (database and similar) need enough time to sync
>> their data and exit.
>
>In my experience, containers running sysvinit usually take ~10s to shut
>down if next to nothing is running inside them (at the very end they
>wait 5s each to send SIGTERM and SIGKILL respectively to all of the
>processes), so I would rather be a bit more conservative and make the
>default 30s or even 60s instead of 15s. Containers with upstart or
>systemd as init system shut down faster, so there it's not quite as
>relevant.
>
>It also would be nice to be able to override the default via
>configuration file, i.e. lxc.timeout.shutdown = 120s. The precenedence
>rule would be: lxc default (30s) overridden by config file overridden by
>command line option. That way, one doesn't always need to specify the
>timeout for a container that one knows to shut down much slower (due to
>a running database or such) and can just do lxc-stop -n foo without
>having to think too much.
>
>> Does that sound reasonable to everyone?
>
>Apart from the comments above: Yes, absolutely.
>
>-- Christian
>
>--------------------------------------------------------------------------
>----
>AlienVault Unified Security Management (USM) platform delivers complete
>security visibility with the essential security capabilities. Easily and
>efficiently configure, manage, and operate all of your security controls
>from a single console and one unified framework. Download a free trial.
>http://p.sf.net/sfu/alienvault_d2d
>

Brent Tubbs
Senior Director, Websites and Portals
YouGov
What the world thinks

285 Hamilton Avenue
Suite #200
Palo Alto, CA 94301
T: +1 650-462-8000
brent.tubbs at yougov.com
http://www.yougov.com


_______________________________________________
>Lxc-devel mailing list
>Lxc-devel at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/lxc-devel
>






More information about the lxc-devel mailing list