| View previous topic :: View next topic |
| Author |
Message |
palettentreter
Tux's lil' helper
Joined: 06 Feb 2006
Posts: 104
|
 Posted: Mon Jan 13, 2014 4:03 pm Post subject: SIGTERM broken? |
 |
|
Hi everyone,
I'm seeing some really amazing breakage in my system. The bottom line is that SIGTERM signals never reach processes running with UID 0. User processes can be terminated regularly. So in effect, I do something like this:
| Code: |
# strace tee
execve("/usr/bin/tee", ["tee"], [/* 56 vars */]) = 0
brk(0) = 0x23c4000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff3c9730000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=329204, ...}) = 0
mmap(NULL, 329204, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff3c96df000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\31\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1721832, ...}) = 0
mmap(NULL, 3828216, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff3c9169000
mprotect(0x7ff3c9306000, 2097152, PROT_NONE) = 0
mmap(0x7ff3c9506000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7ff3c9506000
mmap(0x7ff3c950c000, 14840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff3c950c000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff3c96de000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff3c96dd000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff3c96dc000
arch_prctl(ARCH_SET_FS, 0x7ff3c96dd700) = 0
mprotect(0x7ff3c9506000, 16384, PROT_READ) = 0
mprotect(0x605000, 4096, PROT_READ) = 0
mprotect(0x7ff3c9731000, 4096, PROT_READ) = 0
munmap(0x7ff3c96df000, 329204) = 0
brk(0) = 0x23c4000
brk(0x23e5000) = 0x23e5000
open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3847216, ...}) = 0
mmap(NULL, 3847216, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff3c8dbd000
close(3) = 0
fadvise64(0, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
read(0,
|
Note the absence of any signal related calls here, in particular no sigprocmask() or anything. Now when I send a SIGTERM to this process, simply NOTHING HAPPENS. 
However, SIGINT and SIGHUP do work as expected. And just for completeness' sake: When run with non-root privileges, tee does receive SIGTERM and terminates as expected. And yes, I'm sending signals as root. In another strace I can also see that the kill() call returns normally:
| Code: | | kill(15332, SIGTERM) = 0 |
I noticed this when writing a signal handler in C, and it took me hours of thinking my code was somehow bad, until I finally realized I was dealing with system breakage. 
Can anyone make any sense of this? |
|
| Back to top |
|
 |
PaulBredbury
Watchman
Joined: 14 Jul 2005
Posts: 7310
|
| Posted: Mon Jan 13, 2014 6:21 pm Post subject: |
|
|
| Running nvidia? Check bug. |
|
| Back to top |
|
|
palettentreter
Tux's lil' helper
Joined: 06 Feb 2006
Posts: 104
|
| Posted: Mon Jan 13, 2014 7:10 pm Post subject: |
|
|
Well yes, in fact I do. However I've recently been downgraded to the allegedly stable 304 series which is not mentioned the bug. I was actually aware of the nvidia issue but didn't realize the problem lay with signal masks. Just found that when I start processes on a text console, they do respond normally to SIGTERM. So this seems to be it.
I also had a long-running tmux in which I did all my root work, and now that I completely closed that off, SIGTERM is working in X as well. This tmux process *may* have even been running since I had nvidia-drivers-331* installed, so that would explain everything. Amazing! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
