From owner-freebsd-questions@FreeBSD.ORG Thu Mar 26 19:58:29 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79DF7106564A for ; Thu, 26 Mar 2009 19:58:29 +0000 (UTC) (envelope-from ianrose@eecs.harvard.edu) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.freebsd.org (Postfix) with ESMTP id 53E688FC08 for ; Thu, 26 Mar 2009 19:58:29 +0000 (UTC) (envelope-from ianrose@eecs.harvard.edu) Received: from [192.168.1.104] (c-66-30-192-9.hsd1.ma.comcast.net [66.30.192.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.eecs.harvard.edu (Postfix) with ESMTP id 2872B1A3C24 for ; Thu, 26 Mar 2009 15:40:41 -0400 (EDT) Message-ID: <49CBDA39.10409@eecs.harvard.edu> Date: Thu, 26 Mar 2009 15:40:41 -0400 From: Ian Rose User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: most signals not being delivered to processes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 19:58:29 -0000 Hello, I'm new to this list so if this question is better directed elsewhere please point me in the right direction. 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 still works, but this sort of makes sense since it involves only the OS and doesn't require delivery to the process itself. I have performed a fairly extensive series of tests: using bash: * ctrl-c does nothing * ctrl-z does nothing * kill -XXX works for SIGKILL and SIGSTOP only * kill -XXX 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. using csh (or skip this list and see below for just the diffs with bash): * ctrl-c does interrupt processes (and a C program that traps for SIGINT will catch the signal appropriately from a ctrl-c) * ctrl-z does nothing * kill -XXX works for SIGHUP, SIGINT, SIGKILL, SIGALRM, SIGSTOP, SIGXCPU, SIGXFSZ only * kill -XXX does nothing for all other signals * a C program does not receive a SIGHUP, SIGABRT or SIGTERM that it has sent to itself via 'kill(getpid(), SIGxxx)' * a C program will quit when it sends itself a SIGINT * 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. or, for brevity, here are just the differences when using csh as opposed to bash: * ctrl-c does interrupt processes (and a C program that traps for SIGINT will catch the signal appropriately from a ctrl-c) * kill -XXX works for SIGHUP, SIGINT, SIGALRM, SIGXCPU, SIGXFSZ * a C program will quit when it sends itself a SIGINT This system has been in use for well over a year so I don't know why this would have cropped up all of a sudden. Unfortunately I am not the only one with superuser access on this machine, but nobody else in the group has any idea of what they could have done to mess things up. Some other important details: 1) The problem is not user-specific (other people are seeing the same thing) 2) The problem first appeared Friday (Mar 20) afternoon but it went away after another user re-installed the kernel. But now it returned today. 3) I checked stty -a and my key mapping look fine (e.g. susp = ^Z) Any hints or ideas? thanks very much, Ian