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
I have performed a fairly extensive series of tests:
* 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
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"