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=192.168.0.20:10000 --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.
xprop -root output from the started xterm after successful attach.
pactl info output from the xterm after attach.
xpra server output log when created through systemctl.
Try using start-env
instead:
xpra start :10 --bind-tcp=192.168.0.20:10000 --start="xterm" -d sound --start-env=XDG_RUNTIME_DIR=/tmp/10
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.
xpra sound failure when systemd is enabled and XDG_RUNTIME_DIR environment variable is used.
pactl info output from the xterm after attach reporting the correct values.
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.
Hi Antoine,
I tried with this option as well. The command used was:-
xpra start :10 --bind-tcp=192.168.0.20:10000 --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.
debug diff used.
pactl info after using --env.
log in journalctl -u xpra, The last sections would be more meaningful.
@Kundan: please make sure that you test using r16643 or later.
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.
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.
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
.
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" try: 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)
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=192.168.0.20:10000 --start="xterm" --env=XDG_RUNTIME_DIR=/tmp/10 -d server
Stopping the override of os environment variables by protected_env.
xpra log without applying my diff of stopping overwrite.
xpra log after applying my diff of stop overwrite.
Does r16669 fix things?
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.
Hi Antoine,
I tested with the beta version (xpra version v2.2-r16672) as well. Things are working properly.
Thank you.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1614