Quoting Qiang Huang (h.huangqi...@huawei.com):
> On 2014/1/17 5:38, Serge Hallyn wrote:
> > Quoting S.Çağlar Onur (cag...@10ur.org):
> >> On Thu, Jan 16, 2014 at 4:24 PM, Serge Hallyn <serge.hal...@ubuntu.com>
> >> wrote:
> >>> Quoting S.Çağlar Onur (cag...@10ur.org):
> >>>> 32 and 33 are not defined and causing sigaction to fail. "kill -l" shows
> >>>> following
> >>>> on my system
> >>>>
> >>>> 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5)
> >>>> SIGTRAP
> >>>> 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10)
> >>>> SIGUSR1
> >>>> 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15)
> >>>> SIGTERM
> >>>> 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20)
> >>>> SIGTSTP
> >>>> 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25)
> >>>> SIGXFSZ
> >>>> 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30)
> >>>> SIGPWR
> >>>> 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37)
> >>>> SIGRTMIN+3
> >>>> 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42)
> >>>> SIGRTMIN+8
> >>>> 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47)
> >>>> SIGRTMIN+13
> >>>> 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52)
> >>>> SIGRTMAX-12
> >>>> 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57)
> >>>> SIGRTMAX-7
> >>>> 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62)
> >>>> SIGRTMAX-2
> >>>> 63) SIGRTMAX-1 64) SIGRTMAX
> >>>>
> >>>> Signed-off-by: S.Çağlar Onur <cag...@10ur.org>
> >>>
> >>> Odd... on my system NSIG is 32, so these should never hit (since it is
> >>> in a while i<NSIG loop)
> >>
> >> Printing NSIG via ERROR shows that its 64 on my system.
> >
> > So a header file is #defining NSIG, which is already defined to 32
> > in kernel headers, to _NSIG, which is 64.
> >
> > Looking around the current state of kernel headers, i wonder whether
> > we should imply use min(SIGRTMIN, NSIG).
>
> My box is x86_64, and I got the same result as S.Çağlar.
>
> People may use signal number bigger than SIGRTMIN, so min(SIGRTMIN, NSIG)
> would miss them. Isn't that cause any problems?
>
> Maybe we should just bypass there non-existent signals.
If we could know on any system which signals to bypass that'd be
fine, but AFAICS we can't.
It sounds to me like we should simply ignore failure at sigaction like
we used to :) Something like below. Is that what you meant?
From 87319b691c8f65c7d61ee01e64707d0b59d11caa Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge.hal...@ubuntu.com>
Date: Fri, 17 Jan 2014 08:23:18 -0600
Subject: [PATCH 1/1] lxc_init: don't fail on bad signals
Signed-off-by: Serge Hallyn <serge.hal...@ubuntu.com>
---
src/lxc/lxc_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
index a59dd9c..b86edf8 100644
--- a/src/lxc/lxc_init.c
+++ b/src/lxc/lxc_init.c
@@ -159,8 +159,7 @@ int main(int argc, char *argv[])
act.sa_flags = 0;
act.sa_handler = interrupt_handler;
if (sigaction(i, &act, NULL)) {
- SYSERROR("failed to sigaction");
- exit(EXIT_FAILURE);
+ INFO ("failed to sigaction (%d)", i);
}
}
--
1.8.5.2
_______________________________________________
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
