Re: most signals not being delivered to processes
On Thursday 26 March 2009 21:50:36 Ian Rose wrote: However, hopefully the problem has gone away. Another member of our team thinks that somehow the issue is related to some system services (sshd and dhcpd) failing to completely detach from their controlling terminal due to a setuid wrapper he set up, and thus they are left holding on to some old bad controlling terminal even though they daemonize themselves. As a hint to your team member, daemon(8) program allows one to switch user before daemonizing and detaches properly when asked to. If he wishes to implement this in C himself, visit the setusercontext(3) manpage, which does the setuid() and login class limits automagically. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: most signals not being delivered to processes
Hi, Ian-- On Mar 26, 2009, at 12:40 PM, Ian Rose wrote: I'm new to this list so if this question is better directed elsewhere please point me in the right direction. Welcome; this list is a good place. My research group has a server running 7.2-PRERELEASE and an odd problem has cropped up: most signals are not being delivered to processes. For example, if I run 'sleep 10' from the shell, ctrl-c won't interrupt it. kill -KILL pid still works, but this sort of makes sense since it involves only the OS and doesn't require delivery to the process itself. Both your shells and /bin/kill should be using kill(2) system call; see /usr/src/bin/kill/kill.c, /usr/src/contrib/tcsh/sh.proc.c, etc for the details. For a signal to work, the OS does deliver it to the process, which must be in a runnable state or else delivery will block until the process has returned from a system call or whatever is blocking it. I have performed a fairly extensive series of tests: using bash: * ctrl-c does nothing * ctrl-z does nothing * kill -XXX pid works for SIGKILL and SIGSTOP only * kill -XXX pid does nothing for all other signals * a C program does not receive a SIGHUP, SIGINT, SIGABRT or SIGTERM that it has sent to itself via 'kill(getpid(), SIGxxx)' * a C program will react appropriately when it sends itself a SIGKILL or SIGSTOP * a C program will react appropriately when you call abort(3) * a C program will die with the error Floating point exception: 8 (core dumped) if it divides by zero, but not if it sends itself a SIGFPE. That's significantly odd. What does stty -a say about your control character settings? You should see something like: % stty -a speed 9600 baud; 58 rows; 90 columns; [ ... ] cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; eol2 = undef; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; ...which has the mappings for ^C = SIGINT, ^Z = SIGTSTP, etc. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: most signals not being delivered to processes
Hi Chuck, Thanks for the response. My stty -a looks good: cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; eol2 = undef; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; However, hopefully the problem has gone away. Another member of our team thinks that somehow the issue is related to some system services (sshd and dhcpd) failing to completely detach from their controlling terminal due to a setuid wrapper he set up, and thus they are left holding on to some old bad controlling terminal even though they daemonize themselves. I have to admit I don't completely understand it all (in part because anything involving 'controlling terminals' is usually a bit mystifying for me), but hopefully he's right... cheers, Ian Chuck Swiger wrote: Hi, Ian-- On Mar 26, 2009, at 12:40 PM, Ian Rose wrote: I'm new to this list so if this question is better directed elsewhere please point me in the right direction. Welcome; this list is a good place. My research group has a server running 7.2-PRERELEASE and an odd problem has cropped up: most signals are not being delivered to processes. For example, if I run 'sleep 10' from the shell, ctrl-c won't interrupt it. kill -KILL pid still works, but this sort of makes sense since it involves only the OS and doesn't require delivery to the process itself. Both your shells and /bin/kill should be using kill(2) system call; see /usr/src/bin/kill/kill.c, /usr/src/contrib/tcsh/sh.proc.c, etc for the details. For a signal to work, the OS does deliver it to the process, which must be in a runnable state or else delivery will block until the process has returned from a system call or whatever is blocking it. I have performed a fairly extensive series of tests: using bash: * ctrl-c does nothing * ctrl-z does nothing * kill -XXX pid works for SIGKILL and SIGSTOP only * kill -XXX pid does nothing for all other signals * a C program does not receive a SIGHUP, SIGINT, SIGABRT or SIGTERM that it has sent to itself via 'kill(getpid(), SIGxxx)' * a C program will react appropriately when it sends itself a SIGKILL or SIGSTOP * a C program will react appropriately when you call abort(3) * a C program will die with the error Floating point exception: 8 (core dumped) if it divides by zero, but not if it sends itself a SIGFPE. That's significantly odd. What does stty -a say about your control character settings? You should see something like: % stty -a speed 9600 baud; 58 rows; 90 columns; [ ... ] cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; eol2 = undef; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; ...which has the mappings for ^C = SIGINT, ^Z = SIGTSTP, etc. Regards, ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
