xpra icon
Bug tracker and wiki

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


Opened 7 weeks ago

Closed 6 weeks ago

Last modified 5 weeks ago

#2996 closed defect (invalid)

Delay in opening proxy server sessions

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

Description (last modified by Antoine Martin)

I'm using the proxy server to open sessions from a browser on local wireless connected devices. The sessions always take approximately 30 seconds to open, which is a significant delay.

*

System info: Ubuntu 18.04
XPRA version: 4.0.6-r28284
Using XVFB (I tried XDummy - same result)


Command sequences:
Proxy: xpra proxy --bind-tcp=0.0.0.0:10018 --tcp-auth=allow --debug=proxy,server

Session initiation: http://192.168.2.130:10018/?username=aressecondary&password=Ar3s009!&exit_with_children=1&exit_with_client=1&start=atomix&action=start-desktop


Log attached: Proxy, server

Attachments (4)

:1014.log (80.5 KB) - added by Mark Knittel 7 weeks ago.
XPRA proxy, server log
:1018.log (456.8 KB) - added by Mark Knittel 6 weeks ago.
run-xpra (1000 bytes) - added by Mark Knittel 6 weeks ago.
1.log (5.0 KB) - added by Antoine Martin 6 weeks ago.
sample server log

Download all attachments as: .zip

Change History (16)

Changed 7 weeks ago by Mark Knittel

Attachment: :1014.log added

XPRA proxy, server log

comment:1 Changed 7 weeks ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to Mark Knittel

The server log is missing, as per your proxy log:

Entering daemon mode; any further errors will be reported to:
 /run/user/1000/xpra/S25573.log
(..)
Actual log file name is now: /run/user/1000/xpra/:2.log

Based on your proxy log, the server startup should not take much more than 7 seconds:

  • you process a tcp connection at : 21:37:51,049 process_hello..
  • start the server at: 21:37:51,149 starting new server subprocess...
  • the server starts quickly: 21:37:52,084 displayfd=:2
  • it takes a few more seconds before the proxy sees the sockets as live: 21:37:56,518 identify_new_socket found match: path=/run/user/1000/xpra/ares-desktop-2, display=:2
  • the proxy starts the forwarding process at 21:37:56,520 start_proxy
  • the socket handover completes quickly: 21:37:57,153 received proxy server message: socket-handover-complete
  • it starts forwarding packets from the new server instance: 21:37:58,418 process_server_packet: hello
  • the strange thing is that it takes another 20 seconds after that before it gets to startup-complete: 21:38:16,482 sending to client: b'startup-complete'

During that time the server must be doing something, perhaps processing the printers packet, or starting the audio, intializing a GPU or something.
Impossible to tell without the corresponding log. (you may want to enable -d server logging to get enough details in that log - either with XPRA_SUBPROCESS_DEBUG=server or just adding server to the proxy debug options)

Last edited 7 weeks ago by Antoine Martin (previous) (diff)

Changed 6 weeks ago by Mark Knittel

Attachment: :1018.log added

Changed 6 weeks ago by Mark Knittel

Attachment: run-xpra added

comment:2 Changed 6 weeks ago by Mark Knittel

I'm attaching new logs as requested. I used --debug=all on the proxy initiation. If that does not capture the server info needed please let me know what other commands to use.

Thanks.

comment:3 Changed 6 weeks ago by Antoine Martin

I'm attaching new logs as requested

No, that's just another proxy log. And I'm not sure why you thought the run-xpra script would be relevant here.

As per comment:1, the server log lives somewhere else. In this case, it was in the same location again:

Actual log file name is now: /run/user/1000/xpra/:2.log
Last edited 6 weeks ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 weeks ago by Mark Knittel

I appreciate that, and have been attempting to supply that. However, the file /run/user/1000/xpra/:2.log is empty, and has been each time I run it with different debug settings. I just tried xpra control command to enable server logging, but it still came up empty. I can send the syslog file, but I don't think that's what you want. Is there somewhere else I can look, or is there a config setting that is blocking it?

comment:5 Changed 6 weeks ago by Antoine Martin

However, the file /run/user/1000/xpra/:2.log is empty, and has been each time I run it with different debug settings.

Be aware that the log file may have a different name each time, especially if you launch multiple instances.

I have never seen that file being completely empty.
Messages get logged there almost immediately after it is created, even without any debug logging enabled.

You're using --exit-with-client and --exit-with-children, so the server instance may terminate - try to grab the log before that happens.

comment:6 Changed 6 weeks ago by Mark Knittel

I just tried that - I kept the session open while I checked the logs. Still empty (other than the ones I sent you). I also switched from -d all to -d server and got the same result - it populates the same logs with detail, but not the others. I also turned off debug during proxy initiation and found a small amount of info in the same logs, but much less. It appears that whatever logging -debug server creates is going into the log files I have been sending.

Is there something else I can try to capture the server info?

comment:7 Changed 6 weeks ago by Antoine Martin

I don't have atomix installed, but replacing it with xterm I can see the session coming up within 5 seconds of me hitting the URL.
The server log does show up too, I will attach one I captured as an example.

Version 0, edited 6 weeks ago by Antoine Martin (next)

Changed 6 weeks ago by Antoine Martin

Attachment: 1.log added

sample server log

comment:8 Changed 6 weeks ago by Mark Knittel

Thanks for the input. I tested a couple of other things based on your input:

  • Switched from atomix to xterm. No change - same time to open a session,and no server log output. I've tried at least a dozen desktop apps and they all exhibit the same problem.
  • I did a full re-install of XPRA, including removing all residual files. Same result: session initiation is 30 seconds, and there is no output to the server log. (One note - the /etc/xpra/conf.d folder is empty now. Does that make any sense?)

Are there any other system level or configuration changes you can think of to address this? Im going to try running XPRA on a completely new installation of Ubuntu to see if that helps.

comment:9 Changed 6 weeks ago by Antoine Martin

One note - the /etc/xpra/conf.d folder is empty now. Does that make any sense?

No, it should never be missing if xpra is installed correctly.

My guess is that your installation is borked somehow.
My Ubuntu 18.04 VM is a clean install, it should work the same on your system - bar any hardware differences, perhaps the codec loading takes too long.
Try temporarily doing this:

echo "video-encoders=none" > /etc/xpra/conf.d/99_override.conf
echo "csc-modules=none" > /etc/xpra/conf.d/99_override.conf

comment:10 Changed 6 weeks ago by Mark Knittel

I think it may well be borked as you stated - at least with regards to XPRA. I haven't had any trouble with it other than this, but once I did the reinstall of XPRA the config files are not being reinstalled. I tried the commands you gave me and get a 'permission denied' return, even with sudo.

I did try a fresh install on the same hardware and ran the same commands with XPRA. The load time was around 12 seconds. Not perfect, but good enough, and a major reduction from 30 seconds. I'm going to try to migrate everything to the new installation.

If you have any other ideas let me know. Otherwise you can close this ticket. Thanks for your help.

comment:11 Changed 6 weeks ago by Antoine Martin

Resolution: invalid
Status: newclosed

I think it may well be borked as you stated

A default installation works fast unless proven otherwise, closing.

12 seconds is on the slow side, even my slow VM does it in under 7 seconds, but that's acceptable.

I tried the commands you gave me and get a 'permission denied' return, even with sudo

You have to run them as root, not via sudo, as sudo does not affect the shell past the redirection.

comment:12 Changed 5 weeks ago by migration script

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

Note: See TracTickets for help on using tickets.