Daniel Lezcano <daniel.lezc...@free.fr> writes:
> Ferenc Wagner wrote:
>
>> 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.
>
> 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.
>From 8ba413c1c19cf188d1d1bf1ed72fe26f265c192b Mon Sep 17 00:00:00 2001
From: Ferenc Wagner <wf...@niif.hu>
Date: Thu, 13 May 2010 11:33:59 +0200
Subject: [PATCH] forward control signals to the container init
Signed-off-by: Ferenc Wagner <wf...@niif.hu>
---
src/lxc/start.c | 43 ++++++++++++++++++++++++++++++-------------
1 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/src/lxc/start.c b/src/lxc/start.c
index 7e34cce..58b747f 100644
--- a/src/lxc/start.c
+++ b/src/lxc/start.c
@@ -198,6 +198,16 @@ static int setup_sigchld_fd(sigset_t *oldmask)
return -1;
}
+ sigaddset(&mask, SIGUSR1);
+ sigaddset(&mask, SIGUSR2);
+ sigaddset(&mask, SIGTERM);
+ sigaddset(&mask, SIGCONT);
+ sigaddset(&mask, SIGTSTP);
+ sigaddset(&mask, SIGTTIN);
+ sigaddset(&mask, SIGTTOU);
+ sigaddset(&mask, SIGXCPU);
+ sigaddset(&mask, SIGXFSZ);
+ sigaddset(&mask, SIGWINCH);
if (sigaddset(&mask, SIGCHLD) || sigprocmask(SIG_BLOCK, &mask, oldmask)) {
SYSERROR("failed to set mask signal");
return -1;
@@ -238,22 +248,29 @@ static int sigchld_handler(int fd, void *data,
return -1;
}
- if (siginfo.ssi_code == CLD_STOPPED ||
- siginfo.ssi_code == CLD_CONTINUED) {
- INFO("container init process was stopped/continued");
- return 0;
- }
+ switch (siginfo.ssi_signo) {
+ case SIGCHLD:
+ if (siginfo.ssi_code == CLD_STOPPED ||
+ siginfo.ssi_code == CLD_CONTINUED) {
+ INFO("container init process was stopped/continued");
+ return 0;
+ }
- /* more robustness, protect ourself from a SIGCHLD sent
- * by a process different from the container init
- */
- if (siginfo.ssi_pid != *pid) {
- WARN("invalid pid for SIGCHLD");
+ /* more robustness, protect ourself from a SIGCHLD sent
+ * by a process different from the container init
+ */
+ if (siginfo.ssi_pid != *pid) {
+ WARN("invalid pid for SIGCHLD");
+ return 0;
+ }
+
+ DEBUG("container init process exited");
+ return 1;
+ default:
+ kill(*pid, siginfo.ssi_signo);
+ INFO("forwarded signal %d to %d", siginfo.ssi_signo, *pid);
return 0;
}
-
- DEBUG("container init process exited");
- return 1;
}
int lxc_pid_callback(int fd, struct lxc_request *request,
--
1.6.5
------------------------------------------------------------------------------
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
