Xpra: Ticket #1614: Sound sub-system is not ownering XDG_RUNTIME_DIR when xpra is started from the system proxy server.

Sound sub-system is not ownering the XDG_RUNTIME_DIR when it is getting created through systemd.

xpra Command.

XDG_RUNTIME_DIR=/tmp/10 xpra start :10 --bind-tcp= --start="xterm" -d sound

Due to it, multiple xpra server's with different display no's can't be created with their own pulseaudio servers on Ubuntu 16.04.

I was also, not able to see PULSEAUDIO_SERVER in xprop -root. So, I don't know how the xpra instances and pulseaudio servers are connected.

A current workaround to my problem is:-

systemctl stop xpra

After this, things work as earlier.

Sat, 05 Aug 2017 18:34:24 GMT - Kundan: attachment set

xprop -root output from the started xterm after successful attach.

Sat, 05 Aug 2017 18:35:47 GMT - Kundan: attachment set

pactl info output from the xterm after attach.

Sat, 05 Aug 2017 18:37:19 GMT - Kundan: attachment set

xpra server output log when created through systemctl.

Sat, 05 Aug 2017 18:41:16 GMT - Antoine Martin: owner changed

Try using start-env instead:

xpra start :10 --bind-tcp= --start="xterm" -d sound --start-env=XDG_RUNTIME_DIR=/tmp/10

Sun, 06 Aug 2017 04:11:09 GMT - Kundan: owner changed

Hi Antoine,

I tried the suggested option. After this, the xterm started and attached in the client shows the right pulseaudio server string with pactl info. The pavucontrol started from the xterm also shows the devices correctly.

But, neither microphone forwarding nor speaker forwarding works.

The reason seems to be the failures reported in the xpra log, where neither pactl info nor pactl list is reporting the expected values. Both are refusing the connection.

I am also able to see some other issues in the log like, IndexError: list index out of range

I don't know, whether they are related.

Sun, 06 Aug 2017 04:13:34 GMT - Kundan: attachment set

xpra sound failure when systemd is enabled and XDG_RUNTIME_DIR environment variable is used.

Sun, 06 Aug 2017 04:14:47 GMT - Kundan: attachment set

pactl info output from the xterm after attach reporting the correct values.

Sun, 06 Aug 2017 10:26:14 GMT - Antoine Martin: owner changed

Please try with r16643 or later and --env= instead of --start-env=, as this will affect all the subprocesses, including pactl. (start-env is meant to be used for start and start-child options).

The IndexError is unrelated and was already fixed in r16610.

Mon, 07 Aug 2017 17:08:22 GMT - Kundan:

Hi Antoine,

I tried with this option as well. The command used was:-

xpra start :10 --bind-tcp= --start="xterm" --env="XDG_RUNTIME_DIR=/tmp/10" -d server

But, no luck. xpra failed to create pulseaudio server because, it tried to create with the same pulseaudio string i.e /run/user/<uid>/pulse/native. When I tried on a clean system, with no pulseaudio already running. It doesn't owner the environment variable passed. It simply creates the pulseaudio with default XDG_RUNTIME_DIR. I tried to remove quotes around XDG_RUNTIME_DIR=/tmp/10. But, still couldn't get success.

With, --start-env , at least it used to pick-up the XDG_RUNTIME_DIR. But, failed to start speaker or microphone forwarding. One more issue, which I noted, is that, when pulseaudio is created this way. When we stop the xpra server through xpra stop :10. It doesn't kill the started pulseaudio server automatically.

I tried to add some debug statement to search for the issue. But couldn't make progress. I am attaching the debug statements added and the logs.

Mon, 07 Aug 2017 17:09:46 GMT - Kundan: attachment set

debug diff used.

Mon, 07 Aug 2017 17:10:56 GMT - Kundan: attachment set

pactl info after using --env.

Mon, 07 Aug 2017 17:11:57 GMT - Kundan: attachment set

log in journalctl -u xpra, The last sections would be more meaningful.

Mon, 07 Aug 2017 17:12:07 GMT - Antoine Martin:

@Kundan: please make sure that you test using r16643 or later.

Mon, 07 Aug 2017 17:14:20 GMT - Kundan: attachment set

xpra output of the command used, mentioning pulseaudio daemon already running means pulseaudio won't start because XDG_RUNTIME_DIR variable is same as older.

Mon, 07 Aug 2017 17:19:29 GMT - Kundan:

Hi Antoine,

My xpra version is xpra v2.2-r16643. It seems, it has the changes. I also, verified the server.py file in /usr/lib/python2.7/dist-packages/xpra/scripts directory. It do possess the changes. But, I fail to understand, why it's not working.

Mon, 07 Aug 2017 17:20:59 GMT - Antoine Martin:

Thanks for the logs. It looks like the pam config file needs tweaking for Debian / Ubuntu:

PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth
PAM _pam_load_conf_file: unable to open /etc/pam.d/postlogin

This may prevent #1105 from working as expected, but may actually help here if it causes pam auth to fail!

The XDG_RUNTIME_DIR may actually get updated by the pam authentication. Please try to sprinkle some print statements in xpra/scripts/server.py to see where it gets overriden, maybe it is provided by pam in protected_env.

Tue, 08 Aug 2017 13:17:08 GMT - Antoine Martin:

With the latest r16660 beta builds on Ubuntu 16.04, I have verified that XDG_RUNTIME_DIR is correctly set in the xpra server process and the same value is also used when calling pactl. Pulseaudio starts without errors as long as I use a different env value for XDG_RUNTIME_DIR. If you are still having problems, please apply this patch and post the server log:

--- xpra/sound/pulseaudio/pulseaudio_pactl_util.py	(revision 16610)
+++ xpra/sound/pulseaudio/pulseaudio_pactl_util.py	(working copy)
@@ -38,7 +38,8 @@
     env["LC_ALL"] = "C"
         import subprocess
-        log("running %s", cmd)
+        log.info("running %s with env=%s", cmd, env)
+        log.info("XDG_RUNTIME_DIR=%s", env.get("XDG_RUNTIME_DIR"))
         process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, env=env, close_fds=True)
         from xpra.child_reaper import getChildReaper
         procinfo = getChildReaper().add_process(process, "pactl", cmd, True, True)

Tue, 08 Aug 2017 16:57:57 GMT - Kundan:

Hi Antoine,

But, I am still seeing the issue. It seems your earlier suspicion was right. The OS envrionment variables are getting overwritten, after we have set it to our desired value.

I have created a short diff, where I am disabling the overwrite of os environment variables by protected_env in about 4 instances. And, after that, magically things start to work.

In both the cases i.e with overwrite and without overwrite, I have captured the logs with your provided debug statements. And, i.e also, proving the theory.

The xpra command used.

xpra start :10 --bind-tcp= --start="xterm" --env=XDG_RUNTIME_DIR=/tmp/10 -d server

Tue, 08 Aug 2017 16:59:39 GMT - Kundan: attachment set

Stopping the override of os environment variables by protected_env.

Tue, 08 Aug 2017 17:02:03 GMT - Kundan: attachment set

xpra log without applying my diff of stopping overwrite.

Tue, 08 Aug 2017 17:03:25 GMT - Kundan: attachment set

xpra log after applying my diff of stop overwrite.

Tue, 08 Aug 2017 17:04:33 GMT - Antoine Martin:

Does r16669 fix things?

Tue, 08 Aug 2017 17:40:49 GMT - Kundan:

Hi Antoine,

Yes, I tested the changes by modifying my installed xpra directly, and it is working properly. I will also test the changes in the beta version when it would be available tomorrow.

Thanks again, for the help and support.

Wed, 09 Aug 2017 15:24:52 GMT - Kundan:

Hi Antoine,

I tested with the beta version (xpra version v2.2-r16672) as well. Things are working properly.

Thank you.

Wed, 09 Aug 2017 15:55:31 GMT - Antoine Martin: status changed; resolution set

Sat, 23 Jan 2021 05:29:09 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1614