SIGKILL
Darshan Ghumare
darshan.ghumare at gmail.com
Thu Jan 19 04:03:13 EST 2012
Hi Mulyadi,
On Thu, Jan 19, 2012 at 2:16 PM, Mulyadi Santosa
<mulyadi.santosa at gmail.com>wrote:
> Hi Darshan :)
>
> On Thu, Jan 19, 2012 at 14:03, Darshan Ghumare
> <darshan.ghumare at gmail.com> wrote:
> > Hi Mulyadi,
> >
> > How SIGKILL is handle by Kernel?
> > Does SIGKILL & SIGTSTP handled separately than the rest of the signals?
>
> I hope you don't mind if I cc this answer to kernelnewbies as well.
> Hopefully you will get better answer.
>
No.
>
> Well, SIGKILL is handled like other usual signal. The important point
> to notice is that sigkill is handled entirely in kernel space. What it
> means is that it cannot be overriden in user space (i.e installing
> your own signal handler).
>
> SIGKILL will tell the target process to terminate itself. So it pretty
> much will flow like normal process termination. However, the
> termination will be a bit rough. It will just kill....no time to wait
> for in flight I/O whatsoever.
>
What if, there is one process which is in middle of a syscall which has
infinite loop in it received SIGKILL & there are no other processes in the
system?
>
> SIGSTOP...ehm, I think that is handled in kernel space too. The
> handler will basically move the process out of from run queue to the
> process stopped queue (or something like that, I forgot). Then it
> switch the process state from "running" to "stop". It's not the same
> like "sleep" btw.
>
> Hope it helps....
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120119/a16e93b5/attachment.html
More information about the Kernelnewbies
mailing list