xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 8 months ago

Closed 7 months ago

Last modified 6 months ago

#2951 closed defect (fixed)

Proxy xfce fails to launch applications

Reported by: Mark Knittel Owned by: Mark Knittel
Priority: major Milestone: 4.2
Component: server Version: 4.0.x
Keywords: xfce proxy Cc:

Description

I'm using xpra on Ubuntu 18.04 with proxy enabled. When I launch an xfce desktop session (via browser url) about half of the applications will not launch. The response is: 'failed to execute child process, no such file or directory'. I've tried to find a common thread between the applications that do work, and the ones that do not. When I use a direct session (non-xpra) all of the applications work. Do you have any suggestions on what I need to change to enable the applications that will not launch?

Attachments (1)

xpra2.zip (227.0 KB) - added by Mark Knittel 8 months ago.
Compressed log files

Download all attachments as: .zip

Change History (15)

comment:1 Changed 8 months ago by Antoine Martin

Owner: changed from Antoine Martin to Mark Knittel

Please provide more details as per wiki/ReportingBugs.

In particular, what settings are used on the connect.html page that I assume you are using.
Actual examples of commands that do / don't work would also really help.
What is the server command seen in the process list?
Can you post the server log?

Changed 8 months ago by Mark Knittel

Attachment: xpra2.zip added

Compressed log files

comment:2 Changed 8 months ago by Mark Knittel

The following commands were used to setup the sessions:

  • Proxy startup (via terminal): xpra proxy --bind-tcp=0.0.0.0:10002 --tcp-auth=allow --debug=all
  • Session initiation via browser (Chrome) url:

1) http://192.168.2.131:10002/?username=aressecondary&password=Ar3s009!&exit_with_children=1&exit_with_client=1&start=kgeography&action=start-desktop

(Note: this session worked)

2) http://192.168.2.131:10002/?username=aressecondary&password=Ar3s009!&exit_with_children=1&exit_with_client=1&start=gbrainy&action=start-desktop

(Note: this session worked)

3) http://192.168.2.131:10002/?username=aressecondary&password=Ar3s009!&exit_with_children=1&exit_with_client=1&start=mines&action=start-desktop

(Note: this session failed)

4) http://192.168.2.131:10002/?username=aressecondary&password=Ar3s009!&exit_with_children=1&exit_with_client=1&start=einstein&action=start-desktop

(Note: this session failed.)

Other notes:
1) When I open an xfce4 session via proxy the same applications fail with the message: failed to execute child process yyyyy (no such file or directory)
2) If I initiate the individual session via terminal (xpra start-desktop --start=xfce4-session --bind-tcp=0.0.0.0:10004 --exit-with-client=yes), and then access the application via browser url (http://192.168.2.131:10004) the applications all work normally - no errors.
3) If I initiate an xfce4 session via terminal (xpra start-desktop --start=xfce4-session --bind-tcp=0.0.0.0:10004 --exit-with-client=yes) and then access the xfce4 session via browser url (http://192.168.2.131:10004) all applications work normally - no errors.

It would appear that the issue is somehow related to the proxy session.

I am attaching all log files via a compressed folder.

Thanks for your assistance.

Last edited 8 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 8 months ago by Antoine Martin

Owner: changed from Mark Knittel to Antoine Martin
Status: newassigned

I am seeing some problems, which I will investigate.

FWIW: you can try the beta builds from the 4.1 branch, this seems to work much better here.

comment:4 Changed 8 months ago by Antoine Martin

Owner: changed from Antoine Martin to Mark Knittel
Status: assignednew

Updates:

But AFAICT, none of these things are directly related to your problems.
Only r28042 could have caused problems in some fairly rare cases: only if somehow the audio forwarding fails as soon as the HTML5 client starts and before the connection is really established, so this is unlikely to be the case here since the command should be immaterial.


Looking at your failures in comment:2 :

  • mines does not exist in Ubuntu Bionic, you have to run gnome-mines instead (or the KDE equivallent?)
  • einstein crashes in my test VM (it probably needs something graphics related: randr / opengl, you may want to try to run it via vglrun) - you can launch it from an xterm session to verify
  • xfce4-session works for me, just the screen geometry is a bit off

The other two work OK for me (gbrainy and kgeography).
Be aware that some desktop environment applications (ie: KDE apps) will launch deamons for IPC / application settings. These may cause problems when you have multiple sessions running from the same user account but on different X11 displays.

Please try the latest beta builds and make sure your commands are valid.

comment:5 Changed 8 months ago by Mark Knittel

Thanks for the feedback. Sorry for not correcting the Mines command, it does work. However, I still have a long list of apps that don't want to run. I did try the beta release, but it didn't help (at least so far). I'll try that again in a few days.

I did some more testing with the apps that aren't working. I might be wrong, but it appears to be a permissions issue related to xpra proxy. I ran all of them again from an XFCE4 session. The most common error message is a variation on this: 'Configuration file ".config/khangmanrc" not writable.' Please contact your system administrator. (That was for Khangman; The other apps had the same error message, with a different config/yyyyyrc file each time.) Many of the apps that posted that message continued to run, but quite a few did not, suggesting that they need to config file to operate.

Here are some other error message examples for apps that did not work:

  • Tuxpaint: Error: You have no $HOME environment variable!
  • GoldentDict: Exception: Config::exCantUseHomeDir. Message: Can't use home directory to store GoldenDict preferences
  • OpenDict: Permission denied: '/usr/share/opendict/.opendict' ares@ares-desktop:/usr/share/applications$
  • KIG: Could not find the necessary Kig library, check your installation
  • XDiagnose: Error executing command as another user: Not authorized

I executed all of these from an XFCE4 session that had admin privileges and the ID that was used to install the apps originally.

Thanks.

Last edited 8 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 8 months ago by Antoine Martin

I still have a long list of apps that don't want to run

All the errors you posted are due to permission problems.
Is your proxy running as root?
Only the root user can successfully change user when starting new sessions.

If you run your proxy with the same user account as the xpra server instances, then you have to ensure that the environment is suitable for running desktop applications. (ie: a valid $XDG_RUNTIME_DIR, $HOME, etc..)

but it appears to be a permissions issue related to xpra proxy

It's possible that launching via the proxy changes the environment.
You may want to launch just a plain xterm and compare the output of env from there, both when going via the proxy and when using xpra start directly.

comment:7 Changed 8 months ago by Mark Knittel

I checked to see that the proxy task is running as root - it is. I also checked the env variables for the session used to launch the xfce4 session - it all appears to be valid, but I'll keep checking that.

As you noted, all of the errors that seem to prevent the session launched by the proxy engine from accessing critical control files. I've managed to find some work arounds for a few of the apps, but not all of them. I'll keep trying, but hopefully a future release will address this. If there's some additional tracing I can do please let me know.

One of the things that I'd like to do is switch to a different desktop session environment - both to see if somehow helps, but also because the geometry on the XFCE4 session is not right. I've got Mate, LXQT, and KDE Plasma sessions launched, but not having any luck. I used 'start=mate-session', 'start=lxqt-session', and 'start=kde-session' (and 'start=plasma-session') respectively. Are there other commands that I should be using?

Thanks.

comment:8 Changed 8 months ago by Antoine Martin

As you noted, all of the errors that seem to prevent the session launched by the proxy engine from accessing critical control files.

I think that the pam session is not doing what it should and so the environment is incomplete.

You may also want to look at /usr/lib/systemd/system/xpra.service and maybe change ProtectSystem=strict to ProtectSystem=no and maybe tweak ReadWritePaths.

also because the geometry on the XFCE4 session is not right

Please use a different ticket for that.

I've got Mate, LXQT, and KDE Plasma sessions launched, but not having any luck.

Please post the exact details.
Start an xterm and run your session from there to capture the output easily.

comment:9 Changed 7 months ago by Antoine Martin

Milestone: 4.14.2

comment:10 Changed 7 months ago by Mark Knittel

Thanks. I'll check out that suggestion, and file separate tickets for the others. In the meantime I managed to find a very good work around. I created web links to all of the apps that need to be accessed using xdg-open, and then created a single remote link on a server hosted web page that launches a Firefox window (using a temp profile) with all of the internal links. Firefox opens in a full window (no geometry issues) and everything opens in the same session/window. It works great now (other than the 30+ seconds to open the initial Firefox window). One note that might help - I had to experiment to find a browser that worked. Epiphany (and anything that uses that engine) had the same permission issues. Chrome (and users of that engine) force a new window (which never opens), but Firefox did not have either issue. Not sure why.

comment:11 Changed 7 months ago by Antoine Martin

other than the 30+ seconds to open the initial Firefox window

That's too slow, try switching to Xvfb instead of Xdummy.
And have a look at your proxy and server log.
A regular server startup should only take a few seconds, add a few more for the vfb and a few more again for the proxy.

comment:12 Changed 7 months ago by Mark Knittel

I would appreciate some assistance in finding the source of the 30 second delay opening a new session by proxy. I am using XVFB. I tried turning that off but the result was the same. I have the proxy log. Which server log would you like? Do you want me to open a new ticket, or submit the log as part of this session? I will include the command sequences as well.

Thx.

comment:13 Changed 7 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

Closing, as I assume that the permissions problems came from ProtectSystem=strict and / or missing directories / environment variables.

Do you want me to open a new ticket

Please use a new ticket.

I have the proxy log. Which server log would you like?

The one from the server that takes too long to start.

comment:14 Changed 6 months ago by migration script

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

Note: See TracTickets for help on using tickets.