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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CBEA9C.3040502>