Hi Vincent, > It stays in the epoll loop even while you are sending the signals? Could > you also check what you get with "grep '^Sig' /proc/PID/status"?
Yes, it stays in the epoll loop when sending any signal other than -SIGKILL. I'm poking around with gdb to see if I can see anything. This is the backtrace: (gdb) bt #0 0x0000003bf84e8f23 in __epoll_wait_nocancel () from /lib64/libc.so.6 #1 0x000000000049e886 in _do_poll () #2 0x0000000000406a3b in run_poll_loop () #3 0x0000000000409e61 in main () And here is the output of grep '^Sig' /proc/11537/status SigQ: 3/63840 SigPnd: 0000000000000000 SigBlk: fffffffe7bfa7a26 SigIgn: 0000000000001000 SigCgt: 0000000180300205 Regards, Chris On Fri, Oct 30, 2015 at 3:09 PM, Vincent Bernat <[email protected]> wrote: > ❦ 30 octobre 2015 14:50 -0400, Chris Riley <[email protected]> : > > > Good idea. I just tried and it appears to be in an epoll_wait loop. > > This is after sending the PID SIGTTOU and SIGUSR1. SIGTERM also has no > > effect, the process stays in this epoll_wait loop. > > > > strace -p11537 > > Process 11537 attached - interrupt to quit > > epoll_wait(0, {}, 200, 1000) = 0 > > epoll_wait(0, {}, 200, 1000) = 0 > > epoll_wait(0, {}, 200, 1000) = 0 > > epoll_wait(0, {}, 200, 1000) = 0 > > epoll_wait(0, {}, 200, 1000) = 0 > > epoll_wait(0, {}, 200, 1000) = 0 > > epoll_wait(0, ^C <unfinished ...> > > Process 11537 detached > > It stays in the epoll loop even while you are sending the signals? Could > you also check what you get with "grep '^Sig' /proc/PID/status"? > -- > When one burns one's bridges, what a very nice fire it makes. > -- Dylan Thomas >
