I am using ESD on the client. Whether I use artsd (with ESD as output) or ESD on the server, the problem is the same. ie the problem exists whether KDE or Gnome are used as desktop environments.
It appears the daemon keeps an open TCP connection between the server and client machine. The daemon seems not to listen to other connections. Each daemon appear effectively locked into one user for the client machine.
This can easily be demonstrated by logging into an LTSP4 + sound enabled client. Log out then log in under a different user. The new user will not have sound. Log back out then log back in as the previous user. Sound works again.
If the client is rebooted then the other user logs in first, all other users will be locked out from using sound.
This possibly also wastes resources by keeping a running useless sound daemon process on the server.
I found that sending a HUP signal to the running ESD process on the client machine closes the redundant network connections. This seems to also free resources on the server.
If the HUP signal is sent to a running useful instance of ESD (if there are multiple log-in screens on one client and multiple connection instances to the ESD server) the HUP signal appears not to badly break useful ESD processes. The ESD connections tend to re-establish themselves.
I have written a patch for the screen_session script. This sends a HUP signal to running ESD processes as X is started or respawned after logging out.
This patch appears to completely solve the issue. It does introduce a minor bug; If the user is running multiple X log-ins on one client, logging out of one screen may reset the sound daemon for another screen. This appears to cause a mild annoyance as KDE brings up a dialog. However, the connection re-establishes without user intervention.
The patch can be downloaded from:
ftp://nickhill.co.uk/pub/ltsp4-screen_session-patch-esd.tgz
useage: cd /opt/ltsp/i386/etc patch screen_session /path/to/screen_session.patch
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
