Hacker News Reader

Comment by hectorhector | Hacker News Reader

You can put a signal handler in your program to catch the SIGSTOP and run some code before it gets killed.

You can't catch SIGSTOP or SIGKILL. If you're trying to eliminate a rogue process, you wouldn't as nice as to ask it to politely shut down. It could just refuse. So if you're killing it forcefully, it shouldn't get to print anything. If you're asking it politely, then it can just refuse to die and doesn't need a monitor process to restart it.

In this story this isn't Unix but I imagine the same should apply. If you're trying to terminate something with extreme prejudice, it shouldn't get any chance to print anything.

Maybe they used a heartbeat?

Sure, many things could be done for two processes to monitor each other. The confusing bit is this happening at all:

    id1: Friar Tuck... I am under attack!  Pray save me!

The most reasonable explanations to me seem that either this is wrong and didn't happen, or that it actually came from id2, and the source of the message is falsified just for fun, or in hopes to create additional confusion.

Can't catch those signals, but under a very specific sets of circumstances, they could be... not quite ignored, but basically, that is behavior.

Things which are pending completion of I/O won't die as soon as SIGTERM or SIGKILL are sent to them. If you have ever tried to kill a process which had open file handles on a stale NFS mount, you have experienced this behavior. Causing it to happen deliberately is a lot more challenging, as well as not having a process actually be BLOCKED due to I/O, but it was[1] doable.

[1] haven't tried to do this in about a decade, so won't speak about the currency of this approach, but back then, with some clever assembly and a kernel module, it was doable.

Reply on news.ycombinator.com