NetBSD Problem Report #23794

Received: (qmail 28344 invoked by uid 605); 18 Dec 2003 19:11:31 -0000
Message-Id: <20031218191130.8639411154@narn.netbsd.org>
Date: Thu, 18 Dec 2003 19:11:30 +0000 (UTC)
From: rquinn@sec.sprint.net
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: rquinn@sec.sprint.net
To: gnats-bugs@gnats.NetBSD.org
Subject: Can't kill processes stuck on smbfs IO, but can suspend them and then kill them.
X-Send-Pr-Version: www-1.0

>Number:         23794
>Category:       kern
>Synopsis:       Can't kill processes stuck on smbfs IO, but can suspend them and then kill them.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 18 19:12:00 +0000 2003
>Closed-Date:    Sat Apr 04 16:11:37 +0000 2020
>Last-Modified:  Sat Apr 04 16:11:37 +0000 2020
>Originator:     Rob Quinn
>Release:        NetBSD-current
>Organization:
>Environment:
NetBSD strike 1.6ZG NetBSD 1.6ZG (STRIKE) #91: Thu Dec 18 07:30:53 EST 2003  rquinn@strike:/usr/obj/STRIKE i386

>Description:
I frequently mount smbfs shares from Windows servers, read-only, over a WAN (25 to
75ms latency).  It's easy to get a process into an unkillable state, where even 'kill -9'
will not stop it.  But, I finally realized that a control-Z will stop the process, after
which it's easy to kill, even if I resume (fg) the job and let it start running again.  I
think this is a bug of some kind.....

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->jdolecek 
Responsible-Changed-By: jdolecek 
Responsible-Changed-When: Fri Dec 19 10:14:25 UTC 2003 
Responsible-Changed-Why:  
I take care of SMBFS. 
State-Changed-From-To: open->analyzed 
State-Changed-By: jdolecek 
State-Changed-When: Sun Feb 22 12:46:38 UTC 2004 
State-Changed-Why:  
The networking part of smbfs isn't structured to easily correctly 
support request interruption via signal, so this would require some 
changes to the code - it's not matter of simple bug somewhere. 
I will eventually look at it, but don't expect solution soon. 

From: Rob Quinn <rquinn@sec.sprint.net>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/23794
Date: Mon, 23 Feb 2004 07:32:27 -0500

 > The networking part of smbfs isn't structured to easily correctly support
 > request interruption via signal, so this would require some changes to the
 > code - it's not matter of simple bug somewhere.  I will eventually look at
 > it, but don't expect solution soon.

  Thanks.  It was more frustrating before I realized I could suspend and then
 kill the processes.  How about "umount -f"?  Does it have the same issues?
Responsible-Changed-From-To: jdolecek->kern-bug-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sun, 15 Apr 2012 21:41:40 +0000
Responsible-Changed-Why:
Back to role account, jdolecek left


State-Changed-From-To: analyzed->closed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Sat, 04 Apr 2020 16:11:37 +0000
State-Changed-Why:
Obsolete, SMBFS/nsmb was removed from the tree. Thanks for report.


>Unformatted:

Home	PR Database Search