Ha ha well I have lots of hairs but they're all grey. Anyway, hope youget to spend some of Christmas enjoying it! We got the first white Christmas in a decade here.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Tue, 26 Dec 2017, Mihai Moldovan wrote:
Date: Tue, 26 Dec 2017 04:30:03 +0100 From: Mihai Moldovan <ionic@ionic.de> To: Robert Dinse <nanook@eskimo.com> Cc: x2go-user@lists.x2go.org Subject: Re: [X2Go-User] New x2go broken on Ubuntu 17.10
- On 12/26/2017 02:06 AM, Robert Dinse wrote:
I see that you pushed another update today on Christmas. Things stillseem work but I am curious about arguments to nxagent:
root 13298 6.0 0.0 282796 81308 ? S 17:02 0:02 nxagent -nolisten tcp -nolisten tcp -dpi 96 -D -auth /root/.Xauthority -geometry 800x600 -name X2GO-root-50-1514250167_stDMATE_dp24 :50
In particular the -geometry 800x600 even though I'm set at a screenresolution of 1920x1080 (and it is displaying at the correct resolution in spite of that).
We're always starting whole display sessions with a geometry of 800x600 (which corresponds to the default width and height). You're right that this is probably a bit weird, but the window is resized to the correct size later on and nxagent adjusts to that.
This is pretty much also true for rootless sessions (in which case the window is also immediately resized to spawn the whole display).
Real fullscreen sessions get a geometry value of "fullscreen" instead.
It doesn't really matter to much if resizing is working properly. We could avoid a useless resize operation by pre-determining the display size and passing that as the initial geometry, but there isn't all that much to gain.
Memory usage of nxagent does not seem unreasonable to me, 282k of which81k is in core. FIrefox is around 4GB at times.
That's good to hear! I hope to have squashed most memory hog situations, that mostly boiled down to bugs in the new logging code during the last few days and weeks.
The issue I talked about in my last mail boiled down to using the new -d parameter with nxproxy and enabling info or debug output. Staying on the default warning log level didn't lead to it eating memory quickly, but even so that issue should also be gone now.
This update cost me a few hairs lately.
Mihai