Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Mar 2009 13:30:50 -0700
From:      Chuck Swiger <cswiger@mac.com>
To:        Ian Rose <ianrose@eecs.harvard.edu>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: most signals not being delivered to processes
Message-ID:  <458C5AD3-A517-4253-A866-40685A2FC338@mac.com>
In-Reply-To: <49CBDA39.10409@eecs.harvard.edu>
References:  <49CBDA39.10409@eecs.harvard.edu>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?458C5AD3-A517-4253-A866-40685A2FC338>