[lxc-devel] startup scripts for lxc containers?

[Daniel Lezcano]

Michael Tokarev wrote:
> I wonder how lxc containers are supposed to be
> started up and shut down during (host) system
> startup/shutdown?  I mean, are there any plans
> of this sort, or is it a task for some other
> tools such as virt-manager?
> 
> I'm about to put lxc on production (for isolation
> so far, in order to have different build environments
> and test systems, not for security or somesuch), and
> am writing startup scripts, but so far found the
> whole lot isn't quite uesable as is.
> 
> For example, the 4 most importanrt (to me so far) issues
> are:
> 
>   o lack of "console", there's no clean way to redirect
>     container's console to some file.  Maybe bind-mounting
>     /dev/console to something else will do the trick but
>     some utils checks if /dev/console is actually a char
>     device and not a regular file.
>   o daemon mode (-d) of lxc-start is almost unusable in this
>     context, because it _closes_ all filedescriptors, incl.
>     any (error) output of the container and even its own (!)
>     error output (this is visible in strace, writing to
>     fd#2 gives EBADF).  This is just informational issue,
>     that is, while lxc-start's -d is wrong, setsid(1) works
>     just fine.

lxc-start -d -o mylog sends the console output to the file.

But as you mention it, "some utils checks if /dev/console is actually a 
char device". Maybe, a /dev/pts/X could be bind mounted on the console 
and do the same as the lxc-console.

>   o no way to shut down a container.  This has already been
>     mentioned, but it's still a main issue.  All the suggested
>     so far ways (which are basically boils down to connecting
>     to the container using some "external" means like ssh,
>     sending "shutdown" command, waiting for all the processes
>     to exit and finally using lxc-stop) are too clumsy to be
>     useful.  For now, since all my containers aren't very
>     sensitive to "unexpected" abort, I just run lxc-stop.
>     But if some task(s) needs to be done inside before
>     stopping - like shutting down a database - it will be
>     more difficult.


Aah, yes, yes. shutdown a container is a pain, I agree. It's a missing 
kernel functionality, I several times reported this problem to the 
containers@ mailing list but I had no answer.

Any volunteer to help to write a kernel patch ?