On Fri, 2014-01-17 at 08:24 -0600, Serge Hallyn 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? That would make the most sense to me. What would be the downside to ignoring the failure? Are there any error condition which we should not ignore? The man page indicates that errno has two defined values on failure. Either EINVAL, meaning an invalid signal was specified and we SHOULD ignore it, or EFAULT indicating something wrong with the pointers passed to it, which indicates something seriously wrong in the code. That doesn't mean there might not be others that they didn't think to list... :-P > 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 > -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
_______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel