kern/164705: inability to terminate process in D state
kes-kes at yandex.ru
Thu Feb 2 09:10:10 UTC 2012
The following reply was made to PR kern/164705; it has been noted by GNATS.
From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= <kes-kes at yandex.ru>
To: "Eugene M. Zheganin" <eugene at zhegan.in>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: kern/164705: inability to terminate process in D state
Date: Thu, 2 Feb 2012 11:02:38 +0200
Âû ïèñàëè 2 ôåâðàëÿ 2012 ã., 10:17:46:
>>Synopsis: inability to terminate process in D state
>>Arrival-Date: Thu Feb 02 08:20:11 UTC 2012
>>Originator: Eugene M. Zheganin
EMZ> RealService LLC
EMZ> FreeBSD bsdrookie.norma.com. 8.2-STABLE FreeBSD 8.2-STABLE #0:
EMZ> Mon Jul 25 14:13:03 YEKST 2011
EMZ> emz@:/usr/obj/usr/src/sys/GENERIC amd64
EMZ> There's only two holy grails in FreeBSD: one, nowadays patched
EMZ> but sometimes still haunting FreeBSD, is the panic (livelock,
EMZ> hangup, name it yourself) when the mounted media is physically
EMZ> removed (a diskette, a flash-disk etc).
EMZ> And the second - this is inability to terminate a process when
EMZ> it hangs in D state. Of course, kill -9 didn't work (as always.
EMZ> I'm guessing thi isn't a 'uncatchable uniterruptable signal' as
EMZ> it's man page says, It looks more like 'no big deal, safe to
EMZ> ignore signal, just for a process knows that something is up')
EMZ> Last time I plugged the USB-mouse out of its port to hadle the
EMZ> mess with the cord, and when I plugged it back - hald hanged in
EMZ> the D state, so did all of the usbconfigs and so on.
EMZ> I had to reboot the FreeBSD just to get my mouse back. Like
EMZ> we're back in 1996 with an non-OSR Windows 95.
EMZ> It's completely ridiculous.
EMZ> I'm pretty sure that if you're actually using FreeBSD, then at
EMZ> least once in a lifetime you got the need to kill something, you
EMZ> realise you cannot, and then when trying to understand what the
EMZ> hell is going on you see the magical D letter in ps's output, which means you're doomed.
EMZ> There's always an answer. Reboot loves you.
not always, I have process going to 'T' state (STOP).
and it is not killed even when I run 'reboot'
only hard reboot helps (
as developers sayed:
>A signal cannot forcibly kill a process that is stuck in the kernel.
>Allowing this would put the integrity of the kernel data structures at
>risk and likely cause hangs, data corruption or panics later on.
see: bin/164526: kill(1) can not kill process despite on -KILL
Êîíüêîâ mailto:kes-kes at yandex.ru
More information about the freebsd-bugs