Manually unlock /dev/dsp ?

[Philip Kim]

Hi,

Sometimes an application crashes but leaves /dev/dsp locked (when I
want to play sound with xmms etc. I get the error message that
/dev/dsp is unavailable). Is there any way to manually unlock it ?

When I do /sbin/fuser /dev/dsp no processes are shown, but I still
cannot use /dev/dsp. ?

Or are there any other ways around it ? I use neither aRts nor esd (I
found that both are not supported by very many applications yet), but
use the direct OSS.

Btw, I'm running RH7.1 with the 2.4.7 Kernel, and I use the soundchip
included on my MSI K7T-Turbo (VIA 82C686 Chipset).

thanks for any help, PMK

[Dances With Crows]

On 3 Aug 2001 20:38:51 -0700, Philip Kim staggered into the Black Sun

and said:
>Sometimes an application crashes but leaves /dev/dsp locked (when I
>want to play sound with xmms etc. I get the error message that
>/dev/dsp is unavailable). Is there any way to manually unlock it ?
>When I do /sbin/fuser /dev/dsp no processes are shown, but I still
>cannot use /dev/dsp. ?
>

>Btw, I'm running RH7.1 with the 2.4.7 Kernel, and I use the soundchip
>included on my MSI K7T-Turbo (VIA 82C686 Chipset).

When this application crashes, are you sure it's completely dead? "ps
auxw | more" will show you everything that's running on your system, and
you may be surprised at what it coughs up. If a process is stuck in
state "D", then you cannot kill it--it is in an uninterruptible state,
waiting for a read or write to a device to complete. Generally,
processes stay in state D for fractions of a second at a time (unless
NFS is involved...) and if a process gets stuck there for more than a
couple of seconds, it points to either hardware problems or something
screwy going on in kernel space. Often, the only way to clear a process
that's stuck in state D is to reboot the machine. (Then, you should
find out which piece of shoddy hardware is causing the problem, and
reprogram the hardware with a ball peen hammer.)

If a process is in state "Z" (zombie), then you can get rid of it by
killing its parent process. However, a zombie process should not cause
the symptoms you describe.

Are there any common elements to the applications that crash and leave
/dev/dsp "locked"? Does /usr/bin/foobar die like this 50% of the times
you run it? More info, please....

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / That which does not kill us
http://www.brainbench.com / makes us stranger.
-----------------------------/ --Trevor Goodchild, "AEon Flux"