Hacker News new | ask | show | jobs
by dale_glass 1915 days ago
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.
2 comments
T3OU-736 1915 days ago
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.

link
barbinbrad 1915 days ago
Maybe they used a heartbeat?
link
dale_glass 1915 days ago
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.
link