Markus Schönhaber wrote: > In the meantime I've noticed one thing: under the first user account I > created on the machine, there are no problems at all. With other > accounts, I experience random lockups (main menu doesn't respond > anymore, desktop icons disappear, nautilus hangs etc.). > The difference seems to be that for all accounts except the first, > gnome-session starts an instance of esd. > I did follow the Gnome 2.18 upgrade guide > http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.18-upgrade.xml > which states that one should start the esound service. This seems to > work for the first account, i. e. no esd is spawned upon login but sound > works nevertheless. For the other accounts, an instance of esd is > started and if I experience a lockup, killing this esd process resolves > the issue. > > I have yet to find out what the difference is between the accounts.
The difference seems to be the content of ~/.esd_auth. Applications seem to use the value of this authentication cookie when connecting to the sound server, which decides upon this value whether or not it allows the connection. The cookie in the home directory of the user without problems obviously works. The cookies of the other users don't. ~/.esd_auth is automatically created if it doesn't exist - and the newly created cookie doesn't help authenticating at the sound server. Since the best "documentation" I was able to find is http://www.tux.org/~ricdude/dbdocs/design_docs148.html I don't have the slightest idea how to create a working cookie or how I managed to get the one working cookie in the one account that exhibits no problems. One workaround (short of disabling sound mixing) obviously is to copy the working cookie to the home dir of the account(s) with problems. But I don't like that. So I looked at the configuration of esd: /etc/conf.d/esound contains # Warning: To use global esound daemon, you must also set spawn_options # in /etc/esd/esd.conf to the same protocol (i. e. add "-tcp") and unset # "Enable sound server startup" in gnome-sound-properties for all users # and optionally handle authentization. Great! I should "handle authentization". Too bad that I still do not know how to do that. And I should disable "sound server startup". Too bad that this effectively turns off system sounds - the only reason I enabled it in the first place. Further in /etc/conf.d/esound I had ESD_OPTIONS="-tcp -public" I'm pretty sure I didn't set this manually since I never have had need for network sound. I changed that to ESD_OPTIONS="-promiscuous" which causes esound-esd to use Unix domain sockets instead of tcp sockets and turns off authentication. Since I made this change, I have yet to encounter any lockups (or, for that matter, an additionally spawned esd). But esd -h says [...] -promiscuous start unlocked and owned (disable authenticaton) NOT RECOMMENDED [...] I want all my users to be able to use the sound daemon - does the above warning still apply in this case (because it imposes a risk I do not see)? Regards mks -- [EMAIL PROTECTED] mailing list
