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.
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
CONTAINERPID TTY TIME CMD
jail4173 pts/100: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
CONTAINERPID TTY TIME CMD
jail4173 pts/100:00:00 sleep
# fgrep -i sig /proc/4173/status
SigQ: 1/16382
SigPnd:
SigBlk:
SigIgn:
SigCgt:
# 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:
AB C
1 swallowedOKothers also killed
2 OK child gets extraeverybody gets extra
If we put the first process of the container into a new process group:
AB C
1 swallowedOKothers 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
--
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
