From nobody@FreeBSD.org  Thu Feb  2 08:17:47 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 0CEFA106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  2 Feb 2012 08:17:47 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id EC1108FC21
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  2 Feb 2012 08:17:46 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q128Hkie041479
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 2 Feb 2012 08:17:46 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q128Hks0041478;
	Thu, 2 Feb 2012 08:17:46 GMT
	(envelope-from nobody)
Message-Id: <201202020817.q128Hks0041478@red.freebsd.org>
Date: Thu, 2 Feb 2012 08:17:46 GMT
From: "Eugene M. Zheganin" <eugene@zhegan.in>
To: freebsd-gnats-submit@FreeBSD.org
Subject: inability to terminate process in D state
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         164705
>Category:       kern
>Synopsis:       inability to terminate process in D state
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 02 08:20:11 UTC 2012
>Closed-Date:    Thu Feb 02 09:23:14 UTC 2012
>Last-Modified:  Thu Feb  2 09:40:10 UTC 2012
>Originator:     Eugene M. Zheganin
>Release:        8.2-STABLE
>Organization:
RealService LLC
>Environment:
FreeBSD bsdrookie.norma.com. 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Jul 25 14:13:03 YEKST 2011     emz@:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
There's only two holy grails in FreeBSD: one, nowadays patched but sometimes still haunting FreeBSD, is the panic (livelock, hangup, name it yourself) when the mounted media is physically removed (a diskette, a flash-disk etc).

And the second - this is inability to terminate a process when it hangs in D state. Of course, kill -9 didn't work (as always. I'm guessing thi isn't a 'uncatchable uniterruptable signal' as it's man page says, It looks more like 'no big deal, safe to ignore signal, just for a process knows that something is up')

Last time I plugged the USB-mouse out of its port to hadle the mess with the cord, and when I plugged it back - hald hanged in the D state, so did all of the usbconfigs and so on.

I had to reboot the FreeBSD just to get my mouse back. Like we're back in 1996 with an non-OSR Windows 95.

It's completely ridiculous.
>How-To-Repeat:
I'm pretty sure that if you're actually using FreeBSD, then at least once in a lifetime you got the need to kill something, you realise you cannot, and then when trying to understand what the hell is going on you see the magical D letter in ps's output, which means you're doomed.
>Fix:
There's always an answer. Reboot loves you.

>Release-Note:
>Audit-Trail:

From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= <kes-kes@yandex.ru>
To: "Eugene M. Zheganin" <eugene@zhegan.in>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/164705: inability to terminate process in D state
Date: Thu, 2 Feb 2012 11:02:38 +0200

 , Eugene.
 
   2  2012 ., 10:17:46:
 
 
 >>Number:         164705
 >>Category:       kern
 >>Synopsis:       inability to terminate process in D state
 >>Confidential:   no
 >>Severity:       critical
 >>Priority:       low
 >>Responsible:    freebsd-bugs
 >>State:          open
 >>Quarter:        
 >>Keywords:       
 >>Date-Required:
 >>Class:          sw-bug
 >>Submitter-Id:   current-users
 >>Arrival-Date:   Thu Feb 02 08:20:11 UTC 2012
 >>Closed-Date:
 >>Last-Modified:
 >>Originator:     Eugene M. Zheganin
 >>Release:        8.2-STABLE
 >>Organization:
 EMZ> RealService LLC
 >>Environment:
 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
 >>Description:
 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.
 >>How-To-Repeat:
 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.
 >>Fix:
 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@yandex.ru
 
State-Changed-From-To: open->closed 
State-Changed-By: avg 
State-Changed-When: Thu Feb 2 09:22:32 UTC 2012 
State-Changed-Why:  
The general problem can not be meaningfully resolved. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=164705 

From: Andriy Gapon <avg@icyb.net.ua>
To: bug-followup@FreeBSD.org, eugene@zhegan.in
Cc:  
Subject: Re: kern/164705: inability to terminate process in D state
Date: Thu, 02 Feb 2012 11:16:56 +0200

 Because you used words "completely ridiculous" in your bug report, I have to ask
 you what solution a genius like you can propose for a process which is stuck
 inside a system call (that is, in kernel).
 
 Now to techical side.  FreeBSD has no problem killing processes which execute in
 userland.  When a process is executing in kernel (in a system call), it is
 impossible to kill the process in a completely safe/clean fashion without
 affecting/corrupting internal kernel state.
 
 So bad news is that there will not be a universal kill command that can kill
 anything.
 
 Good news is that processes should never get stuck forever inside the kernel.
 Every time this happens it means that there is a (potentially new) bug in
 kernel, which should be properly reported and then hopefully fixed.
 
 So you will have to report concrete bugs with concrete diagnostics.
 
 See PR 164526 for a reference.
 
 P.S.  In my explanation I've omitted techicalities of kill sending a signal and
 how the signal is delivered to its target process.
 
 -- 
 Andriy Gapon
>Unformatted:
