[lxc-devel] startup scripts for lxc containers?

[Michael Tokarev]

Daniel Lezcano wrote:
> Michael Tokarev wrote:
[]
>>   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.

That's what I tried.  With current git (as of today).
The init process in the container starts by lxc-start with
fd# 0, 1 and 2 closed.  /dev/console is redirected to
system (host) console.

> 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.

lxc-start implicitly mounts some things like devpts/ptmx
and console.  I had to patch it to stop doing these weird
things (because I mount devpts inside the container, and
because I tried to redirect 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.

Missing functionality for what?

For now, I'm ok with notifying the container (using ssh or
other means).  What's missing is inability to kill init
process.  When there's no other processes left but only
two -- init with pid=1 and a shell, I can `kill 1' from
that shell, and it succeeds, but the signal never gets
delivered to init.  It's trivial to add a "shutdown"
script into container that will be executed last and
that will send a signal to process #1 to terminate it.
But this can only be done from _outside_ the container
currently, where such a signal actually gets delivered
and the init process gets terminated.

Maybe you're talking about changing sys_reboot() to
something more sensible for a container?

Thanks!

/mjt

> Any volunteer to help to write a kernel patch ?