On Fri, Jan 24, 2014 at 5:10 AM, Mike Gabriel
<mike.gabr...@das-netzwerkteam.de> wrote:
> Hi Alex,
>
>
> On Do 23 Jan 2014 00:36:37 CET, Oleksandr Shneyder wrote:
>
>> Am 22.01.2014 22:36, schrieb Orion Poplawski:
>>>
>>> With libssh 0.6.0, x2goclient consumes 100% cpu on connection. The
>>> trigger
>>> for this is that ssh_select() was rewritten to use poll() instead of
>>> select().
>>> poll() has a timeout in milliseconds, select() in microseconds.
>>> x2goclient
>>> requests a timeout of 500 microseconds which is getting rounded down to a
>>> timeout of 0 milliseconds for poll().
>>>
>>> However, this still seems to point to some poor coding on the part of
>>> x2goclient that we're using such short timeouts. Why can't we just wait
>>> forever in ssh_select() in SshMasterConnection::channelLoop() ?
>>>
>
>> Hello Orion,
>>
>> We can't wait forever in ssh_select, we must perform other tasks in
>> loop, for example accepting forwarded connections. However, I have
>> already increased a select timeout and made a lot of other changes in
>> ssh code of X2Go Client. The changes are not yet in master GIT because
>> they depend on reverse forwarding fixes, that I made to libssh. As soon
>> as we have libssh packages ready, I'll push my local commits to GIT.
>
>
> I have merged the revtunnel branch of x2goclient.git now into the repo's
> master branch.
>
> For Debian, I already have provided the libssh fixes (0.5.4-2~debX+x2go1
> where X in {6, 7, 8}.
>
> For Ubuntu and our Fedora/EPEL builds this is still pending and on my todo
> list.
>
> Please commit your recent (local) changes on top of the current master HEAD.
Just FYI: This issue now present in two Ubuntu releases: saucy and
trusty. The only way to get around this right now is to use the
nightly builds.
Mike, maybe you can backport this patch to the next stable release?
--
regards,
Reinhard
_______________________________________________
X2Go-Dev mailing list
X2Go-Dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/x2go-dev
