signals not delivered in 7.2-PRERELEASE

I

ianrose

Hello,

First time poster here - if this is not the right forum please accept my apology and point me in the right direction.

My research group has a server running 7.2-PRERELEASE and an odd problem has cropped up: signals are not being delivered to processes at all. 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've also written my own trivial C and python programs that trap various signals and print to stdout when these signals are received, and I am unable to get either program to receive any signals. Similarly I am unable to minimize (ctrl-z, a la SIGSTOP) any running processes.

As to why this has appeared all of a sudden, I don't have any bright ideas. 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.

Any hints or ideas? I have tried googling and searching the FreeBSD mailing lists, but have come up empty so far.

thanks very much,
Ian
 
So you can manipulate processes 'from without', but not 'from within'? Just as a test, could you switch to a different shell (login shell, not a different shell started from the current one) and try again there? This may or may not be as simple as a bungled shell that would be fixed by a recompile/reinstall.
 
DutchDaemon said:
So you can manipulate processes 'from without', but not 'from within'? Just as a test, could you switch to a different shell (login shell, not a different shell started from the current one) and try again there? This may or may not be as simple as a bungled shell that would be fixed by a recompile/reinstall.
Click to expand...

Hmm... not sure what you mean by "from without" and "from within". I should have noted that other users are seeing this problem too, so it doesn't appear to be related to my particular login session, ENV variables, etc.

The problem seems to have magically gone away for now, but it seems that the only thing that anyone did was kill off a bunch of hung dhcpd and sshd processes and then restart dhcpd and sshd. No idea if that's related but if it happens again I'll try the same thing...

<crosses fingers>
 
By "from within" I meant: while inside the execution of a process (Ctl+C during 'sleep 10', Ctl+Z while running a process) -- so: from within the shell during the execution of a process in that shell.

P.S.: if all users have the same shell and the same problems, the shell itself (the binary, /bin/sh, /usr/local/bin/bash, etc.) may be faulty -- that's what I referred to here.
 
Well, the problem's back. Here are the results of a few more 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):

  • 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

confusing! :(
 
btw, key-mappings look correct:
Code: 
% stty -a
speed 38400 baud; 35 rows; 114 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
        -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
        -extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
        brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
        -dtrflow -mdmbuf
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;
 
FYI another team member believes that he has solved the problem. So for now thanks for the effort and wish us luck!
 
Good luck. Please give us a summary afterwards. I'm sure it's quite interesting ;)
 
You must log in or register to reply here.
Back
Top