[lxc-devel] startup scripts for lxc containers?

[Daniel Lezcano]

Michael Tokarev wrote:
> 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).

Mmh, console management sucks in lxc. That needs to be thought again.

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

The init process is protected against signals coming from inside the 
container.

I think it's this commit :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b3bfa0cba867f23365b81658b47efd906830879b

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

Right, I did a simple patch doing to check that:

  if (!is_init_pid_namespace(current)) {
	zap_pid_ns(current->nsproxy->pid_ns);
  }

But it's a too simple patch which does not take care of the different 
cases. It is more interesting to notify the parent of the init process, 
the shutdown was called or the reboot. So the parent can kill init, and 
rerun init if it's a reboot. The mechanism should expendable to take 
into account LINUX_REBOOT_CMD_SW_SUSPEND later with the checkpoint / 
restart.