On Fri, 2014-08-08 at 19:04 -0400, CDR wrote:
> Correct. It is a "cancel fire bullet". I want to ask the developers to
> create a new command that would do this.

So far, I don't see anything you have suggested that can't be solved
using either the runlevel method or the delayed alternate boot group
method.  Both would be far more reliable and deterministic.

You'll be far better off not using the default boot group (i.e. either
NULL or onboot) and delaying the initial startup until after you are
sure you don't need to intervene.

The advantage, in my mind, with the alternate delayed boot group is that
you could, as I do, prioritize certain containers that must be started
(like DNS servers) while others could be deferred.  The deferred ones
could be started out of a cron job with triggers and/or delays by
re-invoking lxc-autostart with the alternate boot group.  Once this
process is started, though, if you were to stop it, you could have some
containers started and some not started and some in-between.

Regards,
Mike

> On Fri, Aug 8, 2014 at 5:48 PM, Tom Weber <[email protected]> 
> wrote:
> > define a runlevel where the containers are not started or boot in single
> > user mode and modify the start script.
> >
> > that cancel mechanism you ask for is like a 'cancel fired bullet' button
> > for a gun.
> >
> >   Tom
> >
> > Am Freitag, den 08.08.2014, 16:50 -0400 schrieb CDR:
> >> After I reboot, the LXC service will start automatically all the
> >> containers marked for auto-start. I have not found a way to stop that
> >> mechanism if I absolutely need that the containers to not start.
> >> Suppose I need to umount the partition to issue an "fsck", etc. How do
> >> I preempt the automatic behavior?
> >> It is something like the Iron Dome. Hundreds of containers are on the
> >> air and will be started, how do you override this behavior?
> >>
> >> On Fri, Aug 8, 2014 at 4:22 PM, Łukasz Górski <[email protected]> wrote:
> >> > Could you perhaps clarify when exactly do you want this command to be
> >> > invoked? Before the reboot or after? If after, perhaps I am mistaken, 
> >> > but it
> >> > doesn't seem to make any sense whatsoever. I suppose you'd need to run 
> >> > it in
> >> > a specific timeframe before the containers are started - how much time it
> >> > takes from the moment you get a working shell after the reboot to the 
> >> > point
> >> > when container booting process starts? If you want to run it before the
> >> > reboot, then I guess some shell scripting most likely would do to disable
> >> > autostart and the re-enable it back again after reboot.
> >> >
> >> > Pozdrawiam
> >> > Łukasz Górski
> >> > Biuro Obsługi Klienta LOKIS
> >> > www.lokis.info
> >> >
> >> > ---
> >> > Informujemy, że realizujemy projekt „Modernizacja serwerów wewnętrznych i
> >> > serwera głównego wraz z konfiguracją”.
> >> > Nr wniosku o dofinansowanie: WND-RPPM – 01. – 01.-00 - 363 /08. Projekt 
> >> > jest
> >> > realizowany przy współudziale środków z EFRR oraz budżetu państwa.
> >> > Więcej informacji o wniosku i konkursach na stronach www.arp.gda.pl
> >> >
> >> >
> >> >
> >> > 2014-08-08 21:21 GMT+02:00 CDR <[email protected]>:
> >> >>
> >> >> Suppose you manage a box with 300 containers, all on autostart=1. One 
> >> >> day
> >> >> you reboot the box but you need to avoid all the contaoners to start. 
> >> >> There
> >> >> should be a command like
> >> >> lxc-cancel-autostart.
> >> >> Does it make sense?
> >> >>
> >> >>
> >> >> On Friday, August 8, 2014, Harald Dunkel <[email protected]> 
> >> >> wrote:
> >> >>>
> >> >>> I am not familiar with Ubuntu's setup, but assuming it supports
> >> >>> sysv-init I would suggest to omit lxc in a dedicated run level.
> >> >>>
> >> >>> If your default run level is 2 (specified in /etc/inittab), then
> >> >>> you could use update-rc.d to omit lxc in run level 3, e.g.
> >> >>>
> >> >>>         # update-rc.d lxc start 20 2 4 5 . stop 20 0 1 3 6 .
> >> >>>
> >> >>> This means lxc is started in run levels 2, 4 and 5, and
> >> >>> stopped in 0, 1, 3 and 6.
> >> >>>
> >> >>> If you need to boot without starting the containers, then you
> >> >>> can choose run level 3 on the kernel command line at boot time,
> >> >>> e.g.
> >> >>>         linux /boot/vmlinuz root= ... quiet 3
> >> >>>
> >> >>> grub2 allows you to modify the kernel command line before booting.
> >> >>> Using telinit you can change the run level at run time, e.g.
> >> >>> 'telinit 2' to switch to run level 2 (to start your containers).
> >> >>>
> >> >>>
> >> >>> Hope this helps
> >> >>> Harri
> >> >>>
> >> >>> _____________________________________________he__
> >> >>>
> >> >>> lxc-users mailing list
> >> >>> [email protected]
> >> >>> http://lists.linuxcontainers.org/listinfo/lxc-users
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >>
> >> >> lxc-users mailing list
> >> >> [email protected]
> >> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > lxc-users mailing list
> >> > [email protected]
> >> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >> _______________________________________________
> >> lxc-users mailing list
> >> [email protected]
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> >
> >
> > _______________________________________________
> > lxc-users mailing list
> > [email protected]
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> [email protected]
> http://lists.linuxcontainers.org/listinfo/lxc-users
> 

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  [email protected]
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users

Reply via email to