Messages in this thread |  | | From | Denis Vlasenko <> | | Subject | Re: Unkillable processes stuck in "D" state running forever | | Date | Sun, 28 Jul 2002 16:09:33 -0200 |
| |
On 28 July 2002 09:35, Federico Sevilla III wrote: > On Sun, Jul 28, 2002 at 06:22:46PM +0800, Federico Sevilla III wrote: > > I have been noticing problems on two of my boxes here with some > > processes somehow getting stuck in "D" state, which cannot be killed > > even by a SIGKILL by root, and stay on running forever. I have noticed > > the problem, so far, on 2.4.18-xfs and 2.4.19-rc2-xfs kernels. > > I do not know how small a tidbit this will be, but together with these > processes stuck in state "D", there is a continuing rise in the load > averages of the system as reported by various interfaces > (top/uptime/w/phpSysInfo). On the system running 2.4.18-xfs this rose to > up to 25 before I eventually rebooted the box. > > Another bit: on the 2.4.18-xfs box, the number of processes getting > stuck in state "D" kept growing. Various `ps ax` and `sync` processes in > particular, would get stuck and stall as I would issue them. It may be > interesting to note that with 2.4.19-rc2-xfs, with which I had my "latest > encounter" with this problem, no `ps ax` or `sync` processes got stuck. > Only the couple of apt-method processes that got stuck (and any new ones > I would launch in an attempt to download a package from the Internet for > installation) were there.
D state processes are sitting in kernel code waiting for something to happen. It is ok to sit in D state for milliseconds, it is acceptable to sit for seconds. If those processes are stuck forever, it's a bug.
Capture Alt-SysRq-T output and ksymoops relevant part Yes it means you should have ksymoops installed and tested, which is easy to get wrong. I've done that too often. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |