I've seen this on Centos 6.5 with the Windows 7 x2go client, both 4.0.2.0.
I tried downgrading the client all the way back to 3.11 with no effect.
One interesting point - a colleague running x2goclient on Ubuntu 12 LTS (client version was 3.99) did *not* experience the problem.
In my environment it makes x2go unusable, so I'm now investigating xpra to get the resume/suspend functionality.
regards Alan
-- Alan Fitch
Am 25.07.2014 um 00:44 schrieb Alan Peter Fitch:
I've seen this on Centos 6.5 with the Windows 7 x2go client, both 4.0.2.0.
I tried downgrading the client all the way back to 3.11 with no effect.
One interesting point - a colleague running x2goclient on Ubuntu 12 LTS (client version was 3.99) did *not* experience the problem.
In my environment it makes x2go unusable, so I'm now investigating xpra to get the resume/suspend functionality.
Mike#1 asked Josh Abraham, who also complained about the issue, to post the output of:
dpkg -l x2goclient dpkg -l libssh-4
Unless Josh replied off-list, we don't have the data yet. Maybe you could pick up where Josh left, before going the xpra route? :-)
Mike#1 will be back from his vacation on 2014-08-03.
-Stefan
Hi Alan,
On Fr 25 Jul 2014 00:44:29 CEST, Alan Peter Fitch wrote:
I've seen this on Centos 6.5 with the Windows 7 x2go client, both 4.0.2.0.
I tried downgrading the client all the way back to 3.11 with no effect.
One interesting point - a colleague running x2goclient on Ubuntu 12 LTS (client version was 3.99) did *not* experience the problem.
In my environment it makes x2go unusable, so I'm now investigating xpra to get the resume/suspend functionality.
Can you detect where exactly the sesion startup hangs?
My guess is that you have an everlasting x2gostartagent process on the
X2Go Server machine that loops endlessly while detecting a free TCP/IP
port for binding its forwarding tunnel endpoints to.
We have to rely on a little testing here. Thanks.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On 25/07/14 20:38, Mike Gabriel wrote:
Hi Alan,
On Fr 25 Jul 2014 00:44:29 CEST, Alan Peter Fitch wrote:
I've seen this on Centos 6.5 with the Windows 7 x2go client, both 4.0.2.0.
I tried downgrading the client all the way back to 3.11 with no effect.
One interesting point - a colleague running x2goclient on Ubuntu 12 LTS (client version was 3.99) did *not* experience the problem.
In my environment it makes x2go unusable, so I'm now investigating xpra to get the resume/suspend functionality. Can you detect where exactly the sesion startup hangs? Hi Mike,
I'll have to try some tests at work on Monday (I'm trying to use it where I work).
There are a couple other of other factors. We run various Electronic Design Automation (EDA) tools. The access is as follows
use x2goclient to access a server running Centos 6.5 and Open Grid Scheduler (OGS).
Launch a terminal on the OGS, e.g. qrsh -q name.q xterm The cluster machines are also running Centos 6.5. qrsh is forwarding X from the cluster machines using ssh X forwarding (it's not actually launching rsh, it's using ssh).
Launch the tool.
For some tools (e.g. Altera Quartus, Xilinx Vivado) the x2goagent usage climbs to about 10% CPU as the graphics update. For Mentor Questasim, the CPU usage climbs to between 70 and 90%, and it takes ages (5 minutes?) for the graphics to refresh and stabilise. During that period, all the windows (the xterm and the EDA tool) are greyed out and don't refresh.
I've tried running strace and there were millions of calls to a system file call. I will send you an excerpt of the log on Monday. I think I attached strace to the process ID of the x2goagent, but I will check that on Monday.
I will also trying running directly on the server, just to check if the ssh -X forwarding to the cluster is significant or not.
The thing that really surprised me was that if you use x2goclient from Ubuntu 12 LTS, everything is fine. It was only access from a Windows 7 x2goclient that was affected.
regards Alan
My guess is that you have an everlasting x2gostartagent process on the
X2Go Server machine that loops endlessly while detecting a free TCP/IP
port for binding its forwarding tunnel endpoints to.We have to rely on a little testing here. Thanks.
Mike
-- Alan Fitch
On 25.07.2014 20:38, Mike Gabriel wrote:
Hi Alan,
On Fr 25 Jul 2014 00:44:29 CEST, Alan Peter Fitch wrote:
I've seen this on Centos 6.5 with the Windows 7 x2go client, both 4.0.2.0.
I tried downgrading the client all the way back to 3.11 with no effect.
One interesting point - a colleague running x2goclient on Ubuntu 12 LTS (client version was 3.99) did *not* experience the problem.
In my environment it makes x2go unusable, so I'm now investigating xpra to get the resume/suspend functionality.
Can you detect where exactly the sesion startup hangs?
My guess is that you have an everlasting x2gostartagent process on the X2Go Server machine that loops endlessly while detecting a free TCP/IP port for binding its forwarding tunnel endpoints to.
We have to rely on a little testing here. Thanks.
Hi Mike, I've done some more testing. I tried running Questasim on the cluster controller node (not on one of the cluster machines) and it was just as bad. Again x2goagent was consuming up to 70% CPU, which was slowing window re-draws right down.
I ran strace -p pid where pid was the process ID of x2go agent, and captured a log. Here is a short extract:
Process 14310 attached - interrupt to quit
ioctl(7, FIONREAD, [0]) = 0
write(7, "\2\"\0\0\0\0\377\377", 8) = 8
ioctl(7, FIONREAD, [0]) = 0
ioctl(7, FIONREAD, [0]) = 0
select(8, [7], [], NULL, {5, 0}) = 1 (in [7], left {4, 998540})
ioctl(7, FIONREAD, [13]) = 0
read(7, "\32\r\22\270#A\2\0\0\0\377\377", 65536) = 13 ioctl(7, FIONREAD, [0]) = 0 ioctl(7, FIONREAD, [0]) = 0 write(7, "\2\"\0\0\0\0\377\377", 8) = 8 ioctl(7, FIONREAD, [0]) = 0 ioctl(7, FIONREAD, [0]) = 0 select(8, [7], [], NULL, {5, 0}) = 1 (in [7], left {4, 995499}) ioctl(7, FIONREAD, [13]) = 0 read(7, "\32\r\22\270#A\2\0\0\0\377\377", 65536) = 13
ioctl(7, FIONREAD, [0]) = 0
ioctl(7, FIONREAD, [0]) = 0
write(7, "\2\"\0\0\0\0\377\377", 8) = 8
ioctl(7, FIONREAD, [0]) = 0
ioctl(7, FIONREAD, [0]) = 0
select(8, [7], [], NULL, {5, 0}) = 1 (in [7], left {4, 998045})
ioctl(7, FIONREAD, [13]) = 0
read(7, "\32\r\22\270#`A\2\0\0\0\377\377", 65536) = 13
I've got 270K(!) of this if there's some way to upload an attachment,
regards Alan
Mike
-- Alan Fitch (Home)
-
Alan Fitch -
Alan Peter Fitch
-
Mike Gabriel -
Stefan Baur