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

[Daniel Lezcano]

On 05/13/2010 02:22 PM, 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:
>>>>
>>>>          
>>>>> 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.
>    

Thanks I will play a bit with it.

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

We have the lxc-start process, parent of the container init, monitoring 
the first process of the container.
This process shall exit only when it's child dies. The 
LXC_TTY_ADD_HANDLER is a signal handler to avoid this process to be 
killed by a Ctrl+C. I suppose with the signal forwarding, we can add 
SIGINT and SIGQUIT to the signals to be forwarded and remove LXC_TTY_*

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

Agree.
>   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?
>    
IMO sending a signal to a group means, we assume the application didn't 
setpgrp/setsid.
AFAICS, a batch manager will spawn an application without knowledge of 
it's behavior. I remember a batch manager was relying on a kernel module 
to track the processes of the job in order to kill them all, but since 
the cgroup exists that is no longer needed. IMHO we can just forward the 
signal to the container init only and we wait a bit to check if this 
feature suffices.

Thanks
   -- Daniel