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

[Daniel Lezcano]

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.

>>> 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.
>>     
>
> Could you please send along your pending fix?  I'd like to experiment
> with signal forwarding, but without stomping on that.
>   

Sure, no problem.

> I noticed something strange:
>
> # lxc-start -n jail -s lxc.mount.entry="/ /tmp/jail none bind 0 0" -s lxc.rootfs=/tmp/jail -s lxc.pivotdir=/mnt /bin/sleep 1000
> (in another terminal)
> # lxc-ps --lxc
> CONTAINER    PID TTY          TIME CMD
> jail        4173 pts/1    00:00:00 sleep
> # kill 4173
> (this does not kill the sleep!)
> # strace -p 4173
> Process 4173 attached - interrupt to quit
> restart_syscall(<... resuming interrupted call ...> = ? ERESTART_RESTARTBLOCK (To be restarted)
> --- SIGTERM (Terminated) @ 0 (0) ---
> Process 4173 detached
> # lxc-ps --lxc
> CONTAINER    PID TTY          TIME CMD
> jail        4173 pts/1    00:00:00 sleep
> # fgrep -i sig /proc/4173/status 
> SigQ:	1/16382
> SigPnd:	0000000000000000
> SigBlk:	0000000000000000
> SigIgn:	0000000000000000
> SigCgt:	0000000000000000
> # kill -9 4173
>
> That is, the jailed sleep process could be killed by SIGKILL only, even
> though (according to strace) SIGTERM was delivered and it isn't handled
> specially.  Why does this happen?
>   

I sent a separate email for this problem in order to avoid confusion 
with the signal forwarding discussion.

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

  -- Daniel