Quoting Christian Seiler ([email protected]): > 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 -d. Therefore, at least from > >> the way I use LXC, it seems to me to be much more sensible to > >> have lxc-start daemonize by default and instead provide flag to > >> keep it in the foreground, which seems to be a use case that is > >> rare in comparison. > >> > >> Obviously, this shouldn't be done for the 1.0 branch, since this > >> breaks the given interface. But could we think about this for > >> the next release (or, if you want to be conservative, the > >> release after that with a warning in the next)? Thoughts? > >> > >> Regards, > >> Christian > > > > And make -F mean 'foreground a console'? > > I don't quite know what you mean by 'foreground a console'. To clear a > few things up, I want to mention a use case for the current current > default behavior that I have: > > lxc-start -n foo -- /bin/bash /tmp/post_container_create_actions > (called from a script that also captures output) > > Obviously, if you mean by 'foreground a console' that it's the same > behavior as currently, so that the above works if I just add a -F, I'm > all for it. If you mean something else, please elaborate. :)
Nope, that's what I mean. Better terminology would be good but I can't think of it. > My suggestion (if you see it the same way I do) would be that I write > three patches: > > 1. First patch adds a -F option for keeping stuff in the foreground. In > this patch, it is simply ignored. This patch can then be backported to > 1.0 in order to create early compatibility. > > 2. Second patch changes default behavior to -d but keeps -d (just does > nothing anymore). This then should NOT be backported. Sounds good. > 3. Third patch changes daemonize behavior of LXC to wait until the > container has left the STARTING state (either RUNNING or some failure), > and use an apropriate exit code. This might be backported, or not. > > 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. > Regards, > Christian > > PS: Btw. I've really, really come to like the -f option of lxc-ls. > Thanks to whoever implemented that. > > _______________________________________________ > lxc-devel mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-devel _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
