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 > 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 ------------------------------------------------------------------------------ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users