Daniel Lezcano <daniel.lezc...@free.fr> writes:
> Ferenc Wagner wrote:
>
>> Daniel Lezcano <daniel.lezc...@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.
------------------------------------------------------------------------------
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
