[Lxc-users] lxc-unshare woes and signal forwarding in lxc-start

[Ferenc Wagner]

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

> Ferenc Wagner wrote:
>
>> Daniel Lezcano <daniel.lezcano at free.fr> writes:
>>   
>>> Ferenc Wagner wrote:
>>>     
>>>> Daniel Lezcano <daniel.lezcano at free.fr> writes:
>>>>         
>>>>> Ferenc Wagner wrote:
>>>>>             
>>>>>> I'd like to use lxc-start as a wrapper, invisible to the parent and
>>>>>> the (jailed) child.  Of course I could hack around this by not
>>>>>> exec-ing lxc-start but keeping the shell around, trap all signals and
>>>>>> lxc-killing them forward.  But it's kind of ugly in my opinion.
>>>>>
>>>>> Ok, got it. I think that makes sense to forward the signals,
>>>>> especially for job management.  What signals do you want to
>>>>> forward?
>>>>
>>>> Basically all of them.  I couldn't find a definitive list of signals
>>>> used for job control in SGE, but the following is probably a good
>>>> approximation: SIGTTOU, SIGTTIN, SIGUSR1, SIGUSR2, SIGCONT, SIGWINCH and
>>>> SIGTSTP.
>>>
>>> Yes, that could be a good starting point. I was wondering about
>>> SIGSTOP being sent to lxc-start which is not forwardable of course,
>>> is it a problem ?
>>
>> I suppose not, SIGSTOP and SIGKILL are impossible to use in application-
>> specific ways.  On the other hand, SIGXCPU and SIGXFSZ should probably
>> be forwarded, too.  Naturally, this business can't be perfected, but a
>> "good enough" solution could still be valuable.
>
> Agree.

I attached a proof-of-concept patch which seems to work good enough for
me.  The function names are somewhat off now, but I leave that for later.

>>>> Looking at the source, the SIGCHLD mechanism could be
>>>> mimicked, but LXC_TTY_ADD_HANDLER may get in the way.
>>>
>>> We should remove LXC_TTY_ADD_HANDLER and do everything in the signal
>>> handler of SIGCHLD by extending the handler. I have a pending fix
>>> changing a bit the signal handler function.

What's the purpose of LXC_TTY_ADD_HANDLER anyway?  I didn't dig into it.

>>>> I'm also worried about signals sent to the whole process group: they
>>>> may be impossible to distinguish from the targeted signals and thus
>>>> can't propagate correctly.
>>>
>>> Good point. Maybe we can setpgrp the first process of the container?
>>
>> We've got three options:
>>   A) do nothing, as now
>>   B) forward to our child
>>   C) forward to our child's process group
>>
>> The signal could arrive because it was sent to
>>   1) the PID of lxc-start
>>   2) the process group of lxc-start
>>
>> If we don't put the first process of the container into a new process
>> group (as now), this is what happens:
>>
>>         A                B                     C
>> 1   swallowed            OK            others also killed
>> 2      OK       child gets extra    everybody gets extra
>>
>> If we put the first process of the container into a new process group:
>>
>>         A                B                     C
>> 1   swallowed            OK            others also killed
>> 2   swallowed   only the child killed          OK
>>
>> Neither is a clear winner, although the latter is somewhat more
>> symmetrical.  I'm not sure about wanting all this configurable...
>
> hmm ... Maybe Greg, (it's an expert with signals and processes), has
> an idea on how to deal with that.

I'd say we should setpgrp the container init, forward all signals we
can to it, and have a configuration option for the set of signals which
should be forwarded to the full process group of the container init.
Or does it make sense to swallow anything?
-- 
Cheers,
Feri.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-forward-control-signals-to-the-container-init.patch
Type: text/x-diff
Size: 2181 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20100513/ebc03590/attachment.patch>