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

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

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'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...
-- 
Thanks,
Feri.