Bug 2286

Summary: esd not killed at end of user session
Product: [Retired] Red Hat Linux Reporter: David Miller <davem>
Component: esoundAssignee: Havoc Pennington <hp>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: azhao, genec
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-04 00:48:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David Miller 1999-04-20 12:07:19 UTC
Enable sounds in either gnome or enlightenment.
Log out of X.
Log back into X as another user, he cannot get sounds
because the old copy of esd is still running as the other

The gnome-session session component might the part which
should be responsible for getting rid of esd, I don't know.

Comment 1 Bill Nottingham 1999-09-25 02:46:59 UTC
*** Bug 2848 has been marked as a duplicate of this bug. ***

Linux supports multiple users, right? Then explain this: the
first user
logs in and enables sound in Gnome and Enlightment,
everything works
fine; when the first user logs out and the second user logs
in, the
second user couldn't use sound support in Enlightment
because "esd"
refuses to run. It turns out that the first user left a
"/tmp/.esd/socket" FIFO file and apparently, "esd" needs to
create that
file for the second user but failed because it already
exists or doesn't
have enough permission to remove it. Removing the socket
file by hand
doesn't solve the problem -- all the audio devices are still
busy for
some reason, even though no "esd" is running at the moment.

I used to complain that the majority of NT programs work for
the user
who installs them but don't work for other non-admin users
(for example
PalmPilot desktop, Office sound support, and many others).
It seems that
"esd" works for the first user but not for anybody there

------- Additional Comments From zurk  06/17/99 21:43 -------
i have this problem with ksound not cleaning up after itself. everyone
who logs in on the console creates a new ksound process and it simply
stays there.

------- Additional Comments From genec  08/02/99 00:24 -------
I also have this problem and have a cirvension (for my particular
situation).  I have added a script as /etc/X11/gdm/PostSession/Default
which issues the command /usr/bin/esdctl unlock

This is run as root but seems to work.

Part of the problem is that there is extremely little documentation on
using esound.

Comment 2 Cristian Gafton 2000-01-27 07:36:59 UTC
Change component to the right one

Comment 3 Havoc Pennington 2000-02-04 00:48:59 UTC
OK I figured it out, and it isn't really a bug but it is very confusing.
There are some minor buglets that contribute to confusion.

The error message esd gives about /tmp/.esd/socket is totally bogus and
you can ignore it. esd doesn't exit, it goes ahead and deletes /tmp/.esd/socket
and creates a new one. This is a buglet.

The real problem is the error messages that come after, about permission denied
on /dev/dsp. The problem is that the permissions on /dev/dsp are changed so that
the user logged on to the console owns the device. This works fine as long
as you only use gdm. However, if a user is logged on to a virtual terminal,
they will own /dev/dsp, and a second user logging in via gdm will not be able
to gain ownership of it. You need to log out all the other console users
and things will work OK.

Look at /etc/security/console.perms for details, and the corresponding man page.

If you want, you can just remove /dev/dsp from /etc/security/console.perms and
instead make it owned by an audio group and give the audio group permission
to write to it. Of course then you have to properly maintain the membership of
the audio group.

If anyone reproduces this bug with no console users logged in except the vt7
user running X, then we can reopen it. However I'm pretty sure it is just a
problem with multiple simultaneous console users fighting over /dev/dsp.