syscall.Kill(-pid, syscall.SIGKILL) not immediate?

<p>i&#39;m using the approach described here:</p> <p><a href="https://medium.com/@felixge/killing-a-child-process-and-all-of-its-children-in-go-54079af94773" rel="nofollow">https://medium.com/@felixge/killing-a-child-process-and-all-of-its-children-in-go-54079af94773</a></p> <p>to kill a process and all of its children. i&#39;ve been watching it in action and i&#39;ve noticed that after issuing the syscall.Kill call, the process and child processes linger for up to 30 seconds before disappearing. has anyone else seen this behavior?</p> <hr/>**评论：**<br/><br/>aboukirev: <pre><p>If the processes perform IO or wait on sync primitive at the time, the kernel may not be able to kill them immediately. Other than that, don&#39;t know what could be happening.</p></pre>cootercodes: <pre><p>good point, it is doing IO. that&#39;s probably it</p></pre>neopointer: <pre><p>Try to kill the same process with kill command and see how it behaves</p></pre>goomba_gibbon: <pre><p>Good idea. I&#39;d be very surprised if this was an issue with Go as it should send the signal immediately.</p></pre>Loves_Portishead: <pre><p>Signals are queued by the kernel and delivered when possible. -9 is an exception to this rule which immediately removes the process from the kernel scheduler.</p> <p>Check &#34;signal mask and pending signals&#34; here: <a href="http://man7.org/linux/man-pages/man7/signal.7.html" rel="nofollow">http://man7.org/linux/man-pages/man7/signal.7.html</a></p></pre>goomba_gibbon: <pre><p>I&#39;m aware of that. SIGKILL can&#39;t be trapped and handled by the application.</p> <p>It should be immediate but I suppose it&#39;s still down to the scheduler ultimately. Using kill -9 should be equivalent to sending a SIGKILL from Go.</p></pre>Loves_Portishead: <pre><p>Sure, I just wanted to mention that SIGKILL is a special case, but <em>normally</em> signals are queued and delivered &#34;as soon as the application can receive one&#34; which is subject to the rules laid out in the man page I linked.</p> <p>Sorry if my post wasn&#39;t helpful, a RTFM rarely is, but in this case, it&#39;s just unexpected that delivering signals can take a while.</p> <p>I think also we&#39;ve all seen that ourselves, frantically hitting a ctrl-c to try and stop a terminal program spooling out the contents of the entire internet (or a binary file :-(!) to the terminal, but it refuses to react. The reasons are similar (although can also have to do with a poorly implemented terminal emulator in that case!)</p></pre>