On 04/30/2014 05:20 PM, John Peacock wrote:
> Yes, Yes, 1024 times Yes!
And 1024 times more!
Speaking of defaults here is another proposal. Since all the lxc-
commands are always invoked using the -n option and specifying a
container name, we could allow for -n to be skipped.
For example if we h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/02/14 16:29, Serge Hallyn wrote:
>
> That won't show you the startup msgs as it will attach you to tty1, not
> /dev/console.
>
Surely the alias was just a vague description. The point is being
able to detach from the console, after the cont
On Fri, 2014-05-02 at 16:00 +0200, Harald Dunkel wrote:
> I haven't seen this suggested before: How about making
>
> lxc-start -n container
>
> an alias for
>
> lxc-start -n container -d
> lxc-console -n container
> ?
I was thinking along those lines too. Literally, if someo
Quoting Harald Dunkel (harald.dun...@aixigo.de):
> I haven't seen this suggested before: How about making
>
> lxc-start -n container
>
> an alias for
>
> lxc-start -n container -d
> lxc-console -n container
That won't show you the startup msgs as it will attach you to
tty1, no
I haven't seen this suggested before: How about making
lxc-start -n container
an alias for
lxc-start -n container -d
lxc-console -n container
?
This would allow me to detach from the container, if I
forgot the "-d" for lxc-start.
Regards
Harri
Quoting Christian Seiler (christ...@iwakd.de):
> Hi,
>
> >When -d is the default, you not only see the problems immediately.
> >It is much worse: stderr of lxc-start is redirected to /dev/null,
> >so you don't even see error messages from lxc-start itself! Such
> >as, cgroupfs is not mounted, or
Hi,
When -d is the default, you not only see the problems immediately.
It is much worse: stderr of lxc-start is redirected to /dev/null,
so you don't even see error messages from lxc-start itself! Such
as, cgroupfs is not mounted, or what not.
I don't think you are making a good argument for
On Fri, 2014-05-02 at 13:42 +0400, Michael Tokarev wrote:
> Usually when you're start the container for the first time, when
> you just configured it, you want to see some error messages
> right on the terminal you start it from. So you can fix it and
> repeat, to hit another configuration error a
30.04.2014 16:26, Christian Seiler wrote:
[]
> However, from personal experience, lxc-start is not quite as user-
> friendly. In >95% of cases, I want to start a container in the
> background and keep it running. There are some cases where I want
> to have it in the foreground and get the output im
On Thu, 01 May 2014 19:19:07 +0200
Christian Seiler wrote:
> Hi there,
>
> >> If there's consensus, I'll get on that.
> >
> > Not sure on (3). Perhaps (3) should make the default behavior be
> > what you describe, but make '-d' mean "immediately return, don't
> > wait for success/fail.
>
> Ye
Hi there,
>> If there's consensus, I'll get on that.
>
> Not sure on (3). Perhaps (3) should make the default behavior be what
> you describe, but make '-d' mean "immediately return, don't wait
> for success/fail.
Yes, that seems like a good idea. Does everyone else agree?
Regards,
Christian
Quoting Christian Seiler (christ...@iwakd.de):
> Hi there,
>
> First of all, thanks for the feedback, it appears I'm not alone in
> wishing that LXC changes this behavior. :-)
>
> >> It has been several times that I have accidentally run lxc-start
> >> without the -d flag and then had to shut the
Hi there,
First of all, thanks for the feedback, it appears I'm not alone in
wishing that LXC changes this behavior. :-)
>> It has been several times that I have accidentally run lxc-start
>> without the -d flag and then had to shut the container down again
>> only to immediately try again with -
I think our original plan to have LXC bind /dev/lxc in the container as
a standard unix socket with a basic plain text communication protocol is
still our best option.
I think initially we probably should allow three additional states:
- READY
- BROKEN
- HALTING
Those would be the only states
Note that this would not work generically. Each distro - and presumably until
we
standardize things, each user - will need to separately (1) install the init job
to write to the pipe, (2) set up the container config to create and bind in
the fifo, and (3) write the program to wait on the fifo wr
Dear Serge,
Nice - a long time ago we discussed such a feature. The wrapper for my current
LXC 0.8.4 production environment scan the log for a special console message to
treat a container as "up and running".
greetings
Guido
On 2014-04-30 15:56, Serge Hallyn wrote:
> [...] and another to only
On Wed, 2014-04-30 at 13:56 +, Serge Hallyn wrote:
> And make -F mean 'foreground a console'?
Yes, Yes, 1024 times Yes!
I have the same issue; -d should be the default and you should have to
ask if you want it to be in the foreground. The old default may have
made sense during early developm
Quoting Christian Seiler (christ...@iwakd.de):
> Hi,
>
> I'd like to hear some comments about the following:
>
> With the release of LXC 1.0, lxc-shutdown and lxc-stop were merged
> and now we have a really nice sane default to stopping containers:
> Just run lxc-stop -n $container and LXC will t
Hi,
I'd like to hear some comments about the following:
With the release of LXC 1.0, lxc-shutdown and lxc-stop were merged
and now we have a really nice sane default to stopping containers:
Just run lxc-stop -n $container and LXC will try to shut down the
container and after a default of 60s it
19 matches
Mail list logo
