[lxc-devel] [PATCH 1/3] lxc-shutdown: switch from script to program using api.
Dwight Engen
dwight.engen at oracle.com
Fri May 17 22:41:43 UTC 2013
+1 from me also, I like it simplified for lxc-stop to just "do the right
thing".
On Fri, 17 May 2013 21:02:22 +0000
Brent Tubbs <brent.tubbs at yougov.com> wrote:
> +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
> >
>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> 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