Potential difficulties with this idea:
- There may be insufficient information about state of the process for the
kernel
to free up some resources. It might require code in drivers to assist.
- Locks or mutexes held by the process should not be freed unless the
resource
the lock is protecting is in a consistent state. This gets very
application
specific.
Robert N. Evans
Software Engineer
S T R A T U S T E C H N O L O G I E S
111 Powdermill Road, Maynard, MA 01754-3409 U.S.A.
* Tel. 978-461-7680 / * Fax. 978-461-3610
robert.evans(a)stratus.com
Amateur Radio Call: N1BE
-----Original Message-----
From: Keller, Tim [mailto:Tim.Keller@stratus.com]
Sent: Friday, March 08, 2002 9:39 AM
To: 'wlug(a)wlug.org'
Subject: [Wlug] itch to scratch...
I'd like to figure out a way to "assassinate" processes that get stuck in
the "waiting IO" state when I know there's no way they'll ever come out of
that state.
I just had to reboot my linux workstation to resolve such an issue. I had
an file system containing mp3's mounted via smbfs. Unknown to me, this
connection had become stale, so when I started up xmms, it hung and
immediately went into the dreaded "waiting IO" state, while holding onto my
sound hardware. I did a df and had that stuck as well, along with the bash
shell I spawned it from.
I think I'd like to write a "SIGMURDER" signal that would tell the kernel to
just through its tables and forcibly unallocate all the resources a
particular process is holding, close all its handles, etc.
So before I even contemplate this endeavor, is their away to already do
this?
Thanks,
Tim.
_______________________________________________
