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

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



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?49CBEA9C.3040502>