Esound normally uses the socket /tmp/.esd-$uid/socket. If you are logged in the console etc, chances are that this socket is already created. This means that the server side PulseAudio will fail to start. Not only the esound module, but the entire daemon. This will cause an error in xinit.log like: Running /opt/thinlinc/etc/xstartup.d/43-tl-pulseaudio-launch (Starting session PulseAudio server) W: [pulseaudio] main.c: Couldn't canonicalize binary path, cannot self execute. E: [pulseaudio] socket-server.c: bind(): Adressen redan upptagen E: [pulseaudio] module.c: Failed to load module "module-esound-protocol-unix" (argument: "auth-cookie="/var/opt/thinlinc/sessions/astrand/1/esd_auth""): initialization failed. E: [pulseaudio] main.c: Module load failed. E: [pulseaudio] main.c: Failed to initialize daemon. Failed to start session PulseAudio server The question is: Is it more important with support for Esound applications, or more important that it typically works to launch a session if already logged in on the console? IMHO, probably the latter. Or, perhaps we can just let the esound module fail?
(In reply to comment #0) > Esound normally uses the socket /tmp/.esd-$uid/socket. If you are logged in the > console etc, chances are that this socket is already created. This means that > the server side PulseAudio will fail to start. Not only the esound module, but > the entire daemon. This will cause an error in xinit.log like: Observed on CentOS 6.8 with GNOME in ThinLinc and XFCE on console.
Another case is if you have multiple ThinLinc sessions.
This has gotten worse because of the fact modern systems will now launch their own Pulseaudio very early in the login (it's a default systemd user unit). For Fedora this means Fedora 28 or later, but I can see a similar configuration on Ubuntu 18.04*. So the result is that on modern distributions our session pulseaudio fails to start, removing the benefits it brings. * Ubuntu's packaging is currently broken so it fails to properly install pulseaudio's unit files, but that could quickly change.
(In reply to comment #3) > For Fedora this means Fedora 28 or later, but I can see a similar configuration > on Ubuntu 18.04*. Note that it doesn't seem like this new behaviour is applied on upgrade, so older systems upgraded to these versions don't seem affected. You can see that something is off though by looking at the vendor preset state: > $ systemctl --user status pulseaudio.service | cat > ● pulseaudio.service - Sound Service > Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
Fixed via bug 6108.
Works fine with build 6045.
