# signals not delivered in 7.2-PRERELEASE



## ianrose (Mar 26, 2009)

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


----------



## DutchDaemon (Mar 26, 2009)

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.


----------



## ianrose (Mar 26, 2009)

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.



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>


----------



## DutchDaemon (Mar 26, 2009)

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.


----------



## ianrose (Mar 26, 2009)

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!


----------



## ianrose (Mar 26, 2009)

btw, key-mappings look correct:

```
% 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;
```


----------



## ianrose (Mar 26, 2009)

FYI another team member believes that he has solved the problem.  So for now thanks for the effort and wish us luck!


----------



## DutchDaemon (Mar 26, 2009)

Good luck. Please give us a summary afterwards. I'm sure it's quite interesting


----------

