From: Gerd K. <kr...@by...> - 2004-10-22 20:00:07
|
BlaisorBlade <bla...@ya...> writes: > > Trying again, seems nobody noticed the first mail ... > Sorry, I noticed it, but this is only a workaround, or not? We want to fully > solve this on the host kernel... But see below. I'm not that familar it ptrace yet (learned alot last days while trying to track that one down), so I'm not fully sure how it should work. Someone also mentioned POSIX doesn't specify that, so there is no reference ... But the new kernel behavior at least somehow makes sense: If the process is ptrace-stopped, then it's really ptraced-stopped and *nothing* is going to happen without the tracer doing something. > > Background: the -rc2 patch introduces a new process state for processes > > being stopped due to being traced, older kernels had the same state for > > processes being stopped due to being traced and being stopped due to > > SIGSTOP. That change has the effect that the process doesn't see the > > SIGKILL instantly when being ptrace-stopped, you have to PTRACE_CONT it > > (and first send the SIGKILL and then PTRACE_CONT to avoid a race). > Well, this is clearer than before. Yea, took me some time to figure that ;) > So, actually, a SIGSTOP'ed process is already killable by SIGKILL, normally? > I'm testing that with 2.6.7 and this is true. Yes. I also think it isn't the the fact that it is SIGSTOP'ed that prevents it from being killed, but the fact that it is in the (new) ptrace-stopped state. > But now I have something even clearer: why don't we use PTRACE_KILL > instead of sending a SIGKILL? This seems a simpler solution, and > the processes we are killing in this case are ptraced. That should work as well I think, will try. Is there some way to figure whenever we are tracing the process with the given PID or not without explicitly passing that info as new argument? So os_kill_process() can decide on its own whenever it should send a SIGKILL or use PTRACE_KILL? Gerd -- return -ENOSIG; |