Kill doesn't send SIGUSR1

hfaua · 2014-05-05 22:04:49

Under my Arch Linux I've encountered weird problem. When I send signal SIGUSR1 to process nothing happens, but when I send SIGUSR2, my program receives the signal. It doesn't matter if I'm using kill (2) system call or /usr/bin/kill.

Here is the simple program in the file receiver.c:

#include <signal.h>

int main(void)
{
    for (;;)
        pause();
}

Compilation:

gcc -g -o receiver receiver.c

Then I run the program in gdb:

gdb ./receiver

And send some signals:

killall -USR1 receiver
killall -USR2 receiver

And the output from gdb is:

(gdb) r
Starting program: [...]/receiver

Program received signal SIGUSR2, User defined signal 2.
0x00007ffff7ae6970 in __pause_nocancel () from /usr/lib/libc.so.6
(gdb)

However on other machine the output is:

(gdb) r
Starting program: [...]/receiver

Program received signal SIGUSR1, User defined signal 1.
0x00007f2a10f5f890 in __pause_nocancel () from /lib64/libc.so.6
(gdb)

It seems that my Arch Linux cannot into sending SIGUSR1. Do you have any suggestions? I've searched in google but didn't find anything related. The same happens when I'm sending SIGUSR1 and SIGUSR2 to other processes (eg. Nautilus) - SIGUSR1 does nothing however SIGUSR2 terminates the process.

My machine:

# uname -a
Linux lenovo 3.14.2-1-ARCH #1 SMP PREEMPT Sun Apr 27 11:28:44 CEST 2014 x86_64 GNU/Linux

Other machine:

# uname -a
Linux student 2.6.32.11 #11 SMP Wed Aug 1 05:16:02 CEST 2012 x86_64 Intel(R) Xeon(R) CPU           X7350  @ 2.93GHz GenuineIntel GNU/Linux

ackalker · 2014-05-07 17:48:13

Just a far, far guess, but do you have any signal traps set in your shell? In Bash, you can list the currently active traps with:

$ trap

Also check your gdb settings (do you have a .gdbinit file hiding somewhere perhaps?). In gdb, you can use:

$ gdb -q receiver # Skip the copyright stuff
Reading symbols from receiver...done.
(gdb) b main
Breakpoint 1 at 0x40050a: file receiver.c, line 6.
(gdb) r
Starting program: /home/miki/proj/c/receiver 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main () at receiver.c:6
6               pause();
(gdb) info handle SIGUSR1
Signal        Stop      Print   Pass to program Description
SIGUSR1       Yes       Yes     Yes             User defined signal 1
(gdb)

If I use `trap` to ignore SIGUSR1, then run gdb with your program, and send it SIGUSR1 from another terminal, gdb shows the received signal, but on continue the process will not exit unless I break in using Ctrl-C and quit gdb:
for example:

$ trap '' USR1 # Set default action for SIGUSR1 to 'ignore'
$ trap
trap -- '' SIGUSR1
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
$ gdb -q receiver
(gdb) r
Starting program: /home/miki/proj/c/receiver 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Program received signal SIGUSR1, User defined signal 1.
0x00007ffff7ae6970 in __pause_nocancel () from /usr/lib/libc.so.6
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7ae6970 in __pause_nocancel () from /usr/lib/libc.so.6
(gdb) q
A debugging session is active.

        Inferior 1 [process 20289] will be killed.

Quit anyway? (y or n) y

When I don't have an active (ignore) trap on SIGUSR1 set, the default action is 'Term', and the process does terminate when I continue it from gdb:

$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
$ gdb -q receiver
Reading symbols from receiver...done.
(gdb) r
Starting program: /home/miki/proj/c/receiver 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Program received signal SIGUSR1, User defined signal 1.
0x00007ffff7ae6970 in __pause_nocancel () from /usr/lib/libc.so.6
(gdb) c
Continuing.

Program terminated with signal SIGUSR1, User defined signal 1.
The program no longer exists.
(gdb) q

Although my results are somewhat different from yours, I hope this will help you with tracking down the cause of your problem.

Last edited by ackalker (2014-05-07 18:15:46)

Dreaming in Code · 2014-08-16 02:58:51

Encoutering the same issue, while I'm doing my homework on signals... It is crazy that SIGUSR1 seems to be not even delivered to my process!

Here is a simple test performed on my machine:

$ uname -a
Linux ZH-Laptop 3.16.1-1-ARCH #1 SMP PREEMPT Thu Aug 14 07:40:19 CEST 2014 x86_64 GNU/Linux
$ trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
trap -- '' SIGTTOU
$ cat >test.c
#include <stdio.h>
#include <unistd.h>

int main() {
    printf("pid: %d\n", getpid());
    pause();
    return 0;
}
$ gcc test.c -o test
$ ./test
pid: 5209

On another terminal:

$ kill -s SIGUSR1 5209

Nothing happened.

However:

$ kill -s SIGUSR2 5209

On the first terminal:

$ ./test
pid: 5209
User defined signal 2

Any idea?

-- EDIT --
Note that I rebooted but the problem persists, so it's not a issue about forgetting to reboot after a kernel update.

Last edited by Dreaming in Code (2014-08-16 03:01:57)

Dreaming in Code · 2014-08-16 03:20:09

This is insane... even raise() cannot deliver SIGUSR1 to myself

Another test:

$ cat >test2.c
#include <stdio.h>

#include <signal.h>
#include <unistd.h>

int main() {
    raise(SIGUSR1);
    getchar();
    raise(SIGUSR2);
    getchar();
    return 0;
}
$ gcc test2.c -g -o test2
$ gdb -q test2
Reading symbols from test2...done.
(gdb) b main
Breakpoint 1 at 0x40054a: file test2.c, line 7.
(gdb) r
Starting program: /home/zh/视频/test2 
Got object file from memory but can't read symbols: File truncated.
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?

Breakpoint 1, main () at test2.c:7
7	    raise(SIGUSR1);
(gdb) info handle SIGUSR1
Signal        Stop	Print	Pass to program	Description
SIGUSR1       Yes	Yes	Yes		User defined signal 1
(gdb) info handle SIGUSR2
Signal        Stop	Print	Pass to program	Description
SIGUSR2       Yes	Yes	Yes		User defined signal 2
(gdb) c
Continuing.
a

Program received signal SIGUSR2, User defined signal 2.
0x00007ffff7a61d67 in raise () from /usr/lib/libc.so.6
(gdb) q
A debugging session is active.

	Inferior 1 [process 6137] will be killed.

Quit anyway? (y or n) y

Trilby · 2014-08-16 12:24:18

I don't know why you are concluding that those signals aren't being raised rather than wondering why they aren't being handled. Add a signal handler to your code and you should he it recieves both signals.

Dreaming in Code · 2014-08-16 12:49:01

Trilby wrote:

I don't know why you are concluding that those signals aren't being raised rather than wondering why they aren't being handled. Add a signal handler to your code and you should he it recieves both signals.

I did add a handler for SIGUSR1, however to simplify the case I used gdb and removed that part.

According to the "info handle SIGUSR1" result, gdb should report SIGUSR1 is received, as it did for SIGUSR2.

Last edited by Dreaming in Code (2014-08-16 12:49:23)

Trilby · 2014-08-16 12:51:45

Maybe it should, but in your example it seems not to.

If you send the same signal from a wide variety of sources, and you are recieving it in only one destination, and you observe the signal is not making the full trip - why conclude that *all* sources are failing? Why not suspect the far more parsimonious answer that the one destination is failing to react as it should ... especially when the latter is so easy to test.

Dreaming in Code · 2014-08-16 13:08:17

Trilby wrote:

Maybe it should, but in your example it seems not to.
If you send the same signal from a wide variety of sources, and you are recieving it in only one destination, and you observe the signal is not making the full trip - why conclude that *all* sources are failing? Why not suspect the far more parsimonious answer that the one destination is failing to react as it should ... especially when the latter is so easy to test.

Thanks, you're right.

Just now I sent SIGUSR1 to my bash, to my nautilus and nothing happened. However when I sent it to my chrome it got killed

So can you think of any reason that my own simple program (and gdb) launched from gnome-terminal cannot receive SIGUSR1?

Last edited by Dreaming in Code (2014-08-16 13:08:38)

Dreaming in Code · 2014-08-16 13:22:52

Just now I googled for "gnome-terminal SIGUSR1", and found this bug report. It's a bug in gdm3, and when I switched to tty SIGUSR1 worked

It feels unbelievable that most of the applications in my system has been running without SIGUSR1 for two months and I noticed no incorrect behavior.

Anyway, thank you for your help

Last edited by Dreaming in Code (2014-08-16 13:25:12)

Trilby · 2014-08-16 14:41:31

All this means is that there is an absence of a default SIGUSR1 handler. This really doesn't mean much. There are default handlers for important signals like SIGTERM, SIGKILL, SIGINT. But SIGUSR1/2 are unique to each program and most commonly not used at all.

So the fact that there is no default behavior for a signal that is not expected to do anything unless a program specifies an action does not seem problematic at all.

Any program that specifies a SIGUSR1 handler has not been running without that signal, as they would receive it as needed. Further, and program that doesn't specify a SIGUSR1 handler shouldn't care if that signal is ever emitted or not.

I think you may be confused about what SIGUSR1/2 are actually for. The system never generates these.

Dreaming in Code · 2014-08-16 15:00:04

Trilby wrote:

All this means is that there is an absence of a default SIGUSR1 handler. This really doesn't mean much. There are default handlers for important signals like SIGTERM, SIGKILL, SIGINT. But SIGUSR1/2 are unique to each program and most commonly not used at all.
So the fact that there is no default behavior for a signal that is not expected to do anything unless a program specifies an action does not seem problematic at all.
Any program that specifies a SIGUSR1 handler has not been running without that signal, as they would receive it as needed. Further, and program that doesn't specify a SIGUSR1 handler shouldn't care if that signal is ever emitted or not.
I think you may be confused about what SIGUSR1/2 are actually for. The system never generates these.

Well I know what SIGUSR1/2 means, because I always (try to) rtfm...

But there is a default action (Ign, Term, Core, Stop, Cont) for signals specified by POSIX, according to `man 7 signal`. The default action for SIGUSR1 and SIGUSR2 is Term.

What GDM 3.12 did is that it *blocked* SIGUSR1 for child processes by default using signal mask according to the bug report, and I don't think programmers would expect SIGUSR1 to be blocked by default and unblock it before using it. This is why even gdb cannot catch SIGUSR1 sent to the simple program; it is masked and blocked, not sent to any handler of the signal.

Arch Linux

#1 2014-05-05 22:04:49

Kill doesn't send SIGUSR1

#2 2014-05-07 17:48:13

Re: Kill doesn't send SIGUSR1

#3 2014-08-16 02:58:51

Re: Kill doesn't send SIGUSR1

#4 2014-08-16 03:20:09

Re: Kill doesn't send SIGUSR1

#5 2014-08-16 12:24:18

Re: Kill doesn't send SIGUSR1

#6 2014-08-16 12:49:01

Re: Kill doesn't send SIGUSR1

#7 2014-08-16 12:51:45

Re: Kill doesn't send SIGUSR1

#8 2014-08-16 13:08:17

Re: Kill doesn't send SIGUSR1

#9 2014-08-16 13:22:52

Re: Kill doesn't send SIGUSR1

#10 2014-08-16 14:41:31

Re: Kill doesn't send SIGUSR1

#11 2014-08-16 15:00:04

Re: Kill doesn't send SIGUSR1

Board footer