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"
