I've now seen a similar case multiple times in the wild - if a process has a thread in uninterruptible sleep (e.g., blocked on a bad disk or a stuck network filesystem) and you kill it, the process dies, but the kernel waits forever for that thread before informing the parent process. The parent doesn't get SIGCHLD, and wait() doesn't return. (So, for example, your favorite init/supervisor won't restart the process or even realize the process has died and raise an alert.) If the thread wasn't the first thread, then the process looks like it's gone and stops having most information in /proc/$pid, but it's still got the thread in /proc/$pid/tasks/.<p>I've taken to calling such a process a "lich," because it's not quite a zombie - the parent can reap a zombie by calling wait(), but the lich has used magic to avoid true death.
> Why? I don't know. I thought it was funny<p>This is the profit.<p>While job searching I went on an interview where I got asked why I did a side gig listed on my resumee. "For friend or for money?" It was neither and I said "I don't know, because programming is fun?"<p>I got hired.
<a href="https://lwn.net/Articles/288056/" rel="nofollow">https://lwn.net/Articles/288056/</a><p>Excerpt:<p>"There are advantages and disadvantages to each type of sleep. Interruptible sleeps enable faster response to signals, but they make the programming harder. Kernel code which uses interruptible sleeps must always check to see whether it woke up as a result of a signal, and, if so, clean up whatever it was doing and return -EINTR back to user space.<p>The user-space side, too, must realize that a system call was interrupted and respond accordingly; <i>not all user-space programmers are known for their diligence in this regard.</i><p>Making a sleep uninterruptible eliminates these problems, but at the cost of being, well, uninterruptible. If the expected wakeup event does not materialize, <i>the process will wait forever and there is usually nothing that anybody can do about it short of rebooting the system.</i><p>This is the source of the dreaded, unkillable process which is shown to be in the "D" state by ps.<p>Given the highly obnoxious nature of unkillable processes, one would think that interruptible sleeps should be used whenever possible. The problem with that idea is that, in many cases, the introduction of interruptible sleeps is likely to lead to application bugs.<p>As recently noted by <i>Alan Cox:</i><p><i>Unix tradition (and thus almost all applications) believe file store writes to be non signal interruptible. It would not be safe or practical to change that guarantee.</i>"<p>That's the <i>whyness</i> to all of this...
Did anybody try to run it? Python part of this PoC depends on python2 module "fuse", which in turn depends on "gunpowder", "a library to facilitate machine learning on large, multi-dimensional images". What is even going on here?<p><pre><code> $ pip2 install fuse
Collecting fuse
Downloading https://files.pythonhosted.org/packages/c3/f6/82777531d0dd0fa1d1b509258873f4b48e1ec702dcf0258214fafb474895/fuse-0.1.3.tar.gz
ERROR: Packages installed from PyPI cannot depend on packages which are not also hosted on PyPI.
fuse depends on gunpowder@ git+https://github.com/funkey/gunpowder@721718b6569b47a2f5d5d6633c76c85f779e25c7</code></pre>
Really neat!<p>Not sure why people care what it's written in. I'm pretty sure people wouldn't complain if this was a blog post written in english rather than a program written in C and python2.