[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