+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.tu...@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" <christ...@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.tu...@yougov.com > http://www.yougov.com > > > _______________________________________________ > >Lxc-devel mailing list > >Lxc-devel@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
