On Fri, Jan 17, 2014 at 9:24 AM, Serge Hallyn <serge.hal...@ubuntu.com> wrote: > 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
Yep make sense and much better than hardcoding 32 and 33 in the loop as I did :) > _______________________________________________ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel -- S.Çağlar Onur <cag...@10ur.org> _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel