[lxc-devel] [PATCH 0/5] Signal stuff v2 and some documentation

Ferenc Wagner wferi at niif.hu
Mon Jul 19 19:53:55 UTC 2010


Daniel Lezcano <daniel.lezcano at free.fr> writes:

> On 07/15/2010 10:07 PM, Ferenc Wagner wrote:
>
>> Daniel Lezcano<daniel.lezcano at free.fr>  writes:
>>    
>>> On 06/09/2010 07:56 PM, Ferenc Wagner wrote:
>>>      
>>>> here are basically the same patches, with some obvious errors corrected
>>>> and some unrelated documentation added.  It actually survived some
>>>> targeted testing in the past days and seems to behave as expected, ie.
>>>>
>>>> # lxc-start -n s -- sh -c "trap 'echo TERM' TERM; sleep 10"
>>>>
>>>> can be interrupted by Ctrl-C from the terminal (the sleep process does
>>>> not ignore the SIGINT sent to the foreground process group by the OS),
>>>> while a
>>>>
>>>> # pkill lxc-start
>>>>
>>>> does not terminate the sleep as the SIGTERM gets forwarded to the shell
>>>> only, which reports it after the sleep expires.  This forwarding
>>>> mechanism makes it possible to plug lxc into our batch queueing system.
>>>        
>>> is it your last version or can I investigate with this patchset ?
>>
>> Yes, this is the version I've been using since I posted it.  I haven't
>> ported it to latest git, but it shouldn't be hard.  It seems to do what
>> I intended, but obviously interferes with the console handling, but that
>> should be rethought anyway, as I see it.
>
> Ok, thanks.  I will take the 2 first patches, so signal forwarding is
> done but without [tc]setpgrp for the moment.

Fine, that's enough for our immediate purposes.

> I just figured out, in your use case, you are using 'lxc-start -n foo
> <prog>'.

Yes.

> You are getting ride of the child reaping (the kernel reparents orphan
> processes to the container's init).

Sorry, I'm afraid I don't understand the "you are getting ride of the
child reaping" part.  Could you please rephrase that?

> The purpose of lxc-init is to reap childs, mount /proc, /dev/shm,
> forward signals to process 2 and support daemons.

This isn't a particularly coherent set in my opinion, and neither is it
documented, so I always regarded lxc-execute as a quick&dirty way to
launch applications in a container.  Reaping orphaned children is the
usual task of init, so that's fine.  Mounting this and that is purely
convenience, lxc-start can do so just as well (and in a configurable
way).  Forwarding signals isn't something a usual init would do, and I
wonder what purpose that serves.  And what does "supporting daemons"
mean exactly?  Does lxc-start exit as soon as it's child exits, leaving
possible other processes in the container running, and thus "leaking" a
cgroup/namespace?  It wouldn't seem like useful behaviour.

> Maybe you already noticed that, but maybe you should use the
> 'lxc-execute -n foo <prog>' (which spawns lxc-init).

The above are just my general concerns with lxc-execute and co.  My main
reason for not using it is that SGE (the job scheduler I use) has a so
called "shepherd" process for playing the role of init for each started
job, so I meant lxc-init would be largely superfluous.

> In this case, it would be more convenient to do [tc]setpgrp in
> lxc-init, so we solve the problem with the console.

I agree with the general idea of treating full-system and application
containers differently in this respect.  But I don't agree with tying
this to lxc-execute, which isn't flexible enough for general use (for
example, what if I don't want /proc in the container?).  I still feel
like console handling in lxc-start should be reworked.

>> Basically, I feel like the container console from the user space PoV
>> should be an alias for a terminal device, just like on a real system.
>> /dev/console isn't virtualized by the kernel, so it shouldn't be
>> accessible from a container, although bind mounting it to some tty is
>> an option in case some program uses it explicitly.
>
> That was the first implementation but the '/sbin/init' process calls
> TIOCSCTTY, borrowing the tty to the current terminal.

Interesting.  What does /sbin/init do exactly?  It hasn't got a
controlling terminal on my systems:

$ ps j 1
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    0     1     1     1 ?           -1 Ss       0   0:17 init [2]  

>> In any case, the "console" presented by lxc-start should always be
>> detachable, preferable even detached by default.
>
> Yep, I will send a matrix with a lxc-execute vs lxc-start vs start()
> common function vs console and hopefully we can find a nice way to fix
> this mess.

Looking forward to it! :)
-- 
Thanks,
Feri.




More information about the lxc-devel mailing list