most signals not being delivered to processes

[Ian Rose]

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 <pid> 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 <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.


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 <pid> works for SIGHUP, SIGINT, SIGKILL, SIGALRM, 
SIGSTOP, SIGXCPU, SIGXFSZ only
     * kill -XXX <pid> 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 <pid> 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