Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why doesn't `kill -9` always work?

noah.org

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Why doesn't `kill -9` always work?

#21

Post by dredmorbius »

agwa wrote: post #8

Do not mount NFS with "soft" unless you really know what you're doing. NFS' behavior to hang is not "stupidity" - it's actually one of the best things about NFS. Applications do not deal well with failed reads/writes. If there's a brief network interruption or the NFS server goes down, it's WAY safer to cause applications to hang until the server comes back. Since NFS is a stateless protocol, when the server comes ba…

Expecting NFS (or any other remote filesystem) to behave as if it were local is a fundamental error.

Time, and speed of light, ultimately matter. If you need assurance, find a way of getting reliability in your system through redundancy and locality. Distinguish between "task has been delegated" and "task has been confirmed completed". Down any other path runs pain, and anyone who tells you otherwise is selling something.

You're going to have to compromise: whole systems (or clusters) going titsup because your NFS heads had a fart, or lost commits. Neither is very attractive when shit's on the line.

Your database relying on NFS is a fundamental error you'll have to design around.

Re: Why doesn't `kill -9` always work?

#22

Post by roryokane »

Trufa wrote: post #15

That site is trying to murder my eyes! Go here http://www.readability.com/articles/zcqkmihi and switch to Readability view!

I use a bookmarklet for that purpose – Zap Colors from https://www.squarefree.com/bookmarklets/zap.html. It resets colors to the browser default while keeping the page layout the same.

Re: Why doesn't `kill -9` always work?

#23

Post by derleth »

dfox wrote: post #18
ambrop7 wrote: post #14

I consider any uninterruptable sleep in the kernel a bug. There's no technical reason a process waiting for a resource (e.g. disk I/O) couldn't be killed on the spot, leaving the resource on its own. If it can't be, it just means it hasn't been implemented in the kernel.

It's bug motivated by compatibility. On original 70's implementations of Unix, file system I/O mostly led to busy wait in kernel and thus was not interruptible because it was simply not possible and there were applications that relied on this behavior. On UNIX, signal received during system call generally causes the kernel to abort whatever it was doing and requires application to deal with that situation and restart…

> [Fixing the bug] was simply not possible and there were applications that relied on this behavior [so now that it's technically possible to fix it, it would break compatibility so much we actually can't fix it anyway.]

I'm beginning to wonder if it's possible to design a platform complex enough to be usable without running into this problem.

Re: Why doesn't `kill -9` always work?

#24

Post by glenstein »

Trufa wrote: post #15

That site is trying to murder my eyes! Go here http://www.readability.com/articles/zcqkmihi and switch to Readability view!

Another (which I originally found because of a comment here a few years ago) is http://viewtext.org/.

I like this one because I can add it as a custom search engine in Opera without adding a browser extension or leaving the page.

Re: Why doesn't `kill -9` always work?

#25

Post by syncsynchalt »

agwa wrote: post #12
jsnell wrote: post #3

Earlier quoted context omitted.

So that whole section doesn't make a lot of sense to me. Running strace on an unkillable process tends to produce no output (if the process was actually making new system calls, it wouldn't be wedged). And worse, my experience is that attaching to a wedged process with ptrace() usually does nothing at all except also hang the attaching the process. This also applies to gdb. And finally, even if attaching worked, gett…

I don't understand it either. The only syscalls going on there are reads from /dev/random and writes to /dev/null - both of those can be interrupted (in fact writes to /dev/null should be instantaneous). I think the author may be conflating applications blocked in system calls (since reads from /dev/random will block if the system lacks entropy) with applications blocked in uninterruptible system calls.

There are no reads from /dev/random successfully happening in the example (not after the first few blocks, anyway).

/dev/random reads from an entropy pool that is quickly exhausted and slowly filled. The kernel will lock a process in D state while waiting for entropy.

If you're expecting a stream of pseudo-random data then you can get that by directing /dev/urandom to /dev/null.

Re: Why doesn't `kill -9` always work?

#26

Post by jrockway »

dredmorbius wrote: post #21
agwa wrote: post #8

Do not mount NFS with "soft" unless you really know what you're doing. NFS' behavior to hang is not "stupidity" - it's actually one of the best things about NFS. Applications do not deal well with failed reads/writes. If there's a brief network interruption or the NFS server goes down, it's WAY safer to cause applications to hang until the server comes back. Since NFS is a stateless protocol, when the server comes ba…

Expecting NFS (or any other remote filesystem) to behave as if it were local is a fundamental error. Time, and speed of light, ultimately matter. If you need assurance, find a way of getting reliability in your system through redundancy and locality. Distinguish between "task has been delegated" and "task has been confirmed completed". Down any other path runs pain, and anyone who tells you otherwise is selling somet…

NFS can be faster than local storage. Compare a very slow tape drive versus a very fast 10Gbps network connection to an NFS server with a huge in-memory cache.

The problem is expecting any filesystem to be reliable.

Re: Why doesn't `kill -9` always work?

#27

Post by asveikau »

dfox wrote: post #18
ambrop7 wrote: post #14

I consider any uninterruptable sleep in the kernel a bug. There's no technical reason a process waiting for a resource (e.g. disk I/O) couldn't be killed on the spot, leaving the resource on its own. If it can't be, it just means it hasn't been implemented in the kernel.

It's bug motivated by compatibility. On original 70's implementations of Unix, file system I/O mostly led to busy wait in kernel and thus was not interruptible because it was simply not possible and there were applications that relied on this behavior. On UNIX, signal received during system call generally causes the kernel to abort whatever it was doing and requires application to deal with that situation and restart…

> implementations of stdio in libc generally do the right thing

Tell me, what is the "right thing" for stdio to do when it sees EINTR? It strikes me that this can't really be solved at the library level. There are times when you'll want to retry and there are times when you'll want to drop your work and surface the error to the caller. Doesn't seem to me like a library can decide which is which. Which is probably why the I/O syscalls need to surface it in the first place. (I'd argue if a library like stdio, which does nothing but wrap syscalls and buffer stuff, can decide it, then there's no need for EINTR to exist at all because the syscall could theoretically make the same decisions.)

Re: Why doesn't `kill -9` always work?

#30

Post by aw3c2 »

glenstein wrote: post #24
Trufa wrote: post #15

That site is trying to murder my eyes! Go here http://www.readability.com/articles/zcqkmihi and switch to Readability view!

Another (which I originally found because of a comment here a few years ago) is http://viewtext.org/ . I like this one because I can add it as a custom search engine in Opera without adding a browser extension or leaving the page.

opera has user style sheets built in. see the "author" and "user" mode. also check out the accessibility layout.

no need to rely on a third party or even tell anyone what you are reading.

Post reply on HN