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@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@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. _______________________________________________