OpenVZ Forum - RDF feed
type: channel
items: [PATCH 2/2] Warn when container-init defaults fatal signals

[PATCH 2/2] Warn when container-init defaults fatal signals
type: item
description: From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH 2/2] Warn when container-init defaults fatal signals Print a warning the first time a container-init (other than global init) forks a child process without explicitly ignoring or handling a fatal signal. Comments in the patch below explain the gory background :-) Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> --- kernel/fork.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) Index: 2.6.23-mm1/kernel/fork.c =================================================================== --- 2.6.23-mm1.orig/kernel/fork.c 2007-10-27 11:46:38.000000000 -0700 +++ 2.6.23-mm1/kernel/fork.c 2007-10-27 11:48:36.000000000 -0700 @@ -966,6 +966,53 @@ static void rt_mutex_init_task(struct ta } /* + * Container-init process must appear like a normal process to its sibling + * in the parent namespace and should be killable (or not) in the usual way. + * + * But it must be immune to any unwanted signals from within its own namespace. + * + * At the time of sending the signal, sig_init_ignore() checks and ignores + * if receiver is container-init and the signal is unwanted. + * + * A limitation with the check in sig_init_ignore() is that if the signal is + * blocked by the container-init at the time of the check, we cannot ignore + * the signal because the container-init may install a handler for the signal + * before unblocking it. + * + * But if the container-init unblocks the signal without installing the handler, + * the unwanted signal will still be delivered to the container-init. If the + * unwanted signal is fatal (i.e default action is to terminate), we end up + * terminating the container-init and hence the container. + * + * There does not seem to be an easy/clean way to address this blocked-signal + * issue in the kernel. For now, it appears easier to let the container-init + * decide what it wants to do with signals i.e have it _explicitly_ ignore or + * handle all fatal …
creator: Sukadev Bhattiprolu
date: 2007-10-27T19:09:28-00:00