Bug 819369

Reopening the bug, since it still occurs in Fedora 17.

+++ This bug was initially created as a clone of Bug #517386 +++

Description of problem:

A had installed the Fedora nx software in F11 - it was running. Now 
trying again, but nothing no more runs correctly: When starting qtnx and 
pressing "connect", after a performed authentication qtnx hangs in 
"process started".

Installed:

nx-3.3.0-35.fc11.i586
freenx-client-0.9-10.fc11.i586
nxcl-0.9-10.fc11.i586
qtnx-0.9-10.fc11.i586
Version-Release number of selected component (if applicable):


How reproducible:
Each time

Steps to Reproduce:
1.Start qtnx
2.Enter UID, password and target host
3.Press connect
  
Actual results:

After a performed authentication qtnx hangs in 
"process started".

See description!

Expected results:
Get connetcted.

Additional info:

Testing with nxclient-3.3.0-6.i386.rpm from nomachine.com runs perfectly.

--- Additional comment from joachim.backes.de on 2009-08-14 04:18:11 EDT ---

qtnx logging output:
====================

Process started
stderr> Pseudo-terminal will not be allocated because stdin is not a terminal.

stdout> HELLO NXSERVER - Version 3.2.0-73 OS (GPL, using backend: 3.2.0)
NX> 105 
stdin>  hello NXCLIENT - Version 3.0.0

stdout> hello NXCLIENT - Version 3.0.0
NX> 134 Accepted protocol: 3.0.0
NX> 105 
stdin>  SET SHELL_MODE SHELL

stdout> SET SHELL_MODE SHELL
NX> 105 
stdin>  SET AUTH_MODE PASSWORD

stdout> SET AUTH_MODE PASSWORD
NX> 105 
stdin>  login

stdout> login
NX> 101 User: 
stdin>  backes

stdout> backes
NX> 102 Password: 
Authenticating client
stdin>  ********
stdout> 

stdout> NX> 103 Welcome to: lindb.rhrk.uni-kl.de user: backes
NX> 105 
stdin>  listsession --user="backes" --status="suspended,running" --geometry="1280x1024x24+render" --type="unix-gnome"

stdout> listsession --user="backes" --status="suspended,running" --geometry="1280x1024x24+render" --type="unix-gnome"

stdout> NX> 127 Sessions list of user 'backes' for reconnect:

Display Type             Session ID                       Options  Depth Screen         Status      Session Name
------- ---------------- -------------------------------- -------- ----- -------------- ----------- ------------------------------


NX> 148 Server capacity: not reached for user: backes
NX> 105 
stdin>  startsession --session="lindb" --type="unix-gnome" --cache="8M" --images="32M" --cookie="29761947848987282692692764008126636494" --link="adsl" --render="1" --encryption="1" --backingstore="when_requested" --imagecompressionmethod="2" --geometry="1024x768+0+0" --screeninfo="1280x1024x24+render" --keyboard="defkeymap" --kbtype="pc102/defkeymap" --media="0" --agent_server="" --agent_user="" --agent_password="" --title="sebtest"

stdout> startsession --session="lindb" --type="unix-gnome" --cache="8M" --images="32M" --cookie="******" --link="adsl" --render="1" --encryption="1" --backingstore="when_requested" --imagecompressionmethod="2" --geometry="1024x768+0+0" --screeninfo="1280x1024x24+render" --keyboard="defkeymap" --kbtype="pc102/defkeymap" --media="0" --agent_server="" --agent_user="" agent_password="******"sebtest" 


stdout> NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0)

stdout> NX> 700 Session id: lindb.rhrk.uni-kl.de-2002-D734CD7D147DA54866132FB38A18CD65

stdout> NX> 705 Session display: 2002
NX> 703 Session type: unix-gnome
NX> 701 Proxy cookie: 8951d647baf9f9dbeb8e0eb6c532ec1d

stdout> NX> 702 Proxy IP: 127.0.0.1
NX> 706 Agent cookie: 8951d647baf9f9dbeb8e0eb6c532ec1d
NX> 704 Session cache: unix-gnome
NX> 707 SSL tunneling: 1
NX> 1009 Session status: starting
NX> 710 Session status: running
NX> 1002 Commit
NX> 105 
stdin>  bye

stderr> /usr/libexec/nx/nxserver: line 1531: 17051 Terminated              sleep $AGENT_STARTUP_TIMEOUT
NX> 1006 Session status: running

stdout> bye

stderr> Bye
NX> 999 Bye

Starting NX proxy
Process started

--- Additional comment from slymidnight on 2009-08-19 14:59:31 EDT ---

Glad to see I'm not the only one who got this...I am regrettably using the official NoMachine nxclient rpm package to connect to my nx server because of this...

--- Additional comment from slymidnight on 2009-08-19 15:00:32 EDT ---

Oh, and not sure if this matters, but the machine I'm getting this on, is x86_64, but I see yours  is i586 so maybe its not platform specific.

--- Additional comment from joachim.backes.de on 2009-08-20 05:35:02 EDT ---

(In reply to comment #2)
> Glad to see I'm not the only one who got this...I am regrettably using the
> official NoMachine nxclient rpm package to connect to my nx server because of
> this...  

Me too since this behaviour arose.

--- Additional comment from axel.thimm on 2009-09-02 16:01:32 EDT ---

(In reply to comment #0)
> A had installed the Fedora nx software in F11 - it was running. Now 
> trying again, but nothing no more runs correctly:

Did you update the client, the server or both? Since there were updates in both packages in the last weeks it would be useful to see which one broke the setup.

--- Additional comment from joachim.backes.de on 2009-09-03 02:12:52 EDT ---

The most recent qtnx version qtnx-0.9-10.fc11.i586 is installed since August 13, and a search in updates-testing was without success.

I have no influence on the server sides (RH EL 5.3/Centos 5/Fedora 9)

--- Additional comment from axel.thimm on 2009-09-03 09:12:34 EDT ---

OK, can you please try to downgrade to qtnx from freenx-client-0.9-8 (from the release)?

--- Additional comment from joachim.backes.de on 2009-09-03 10:03:15 EDT ---

(In reply to comment #7)
> OK, can you please try to downgrade to qtnx from freenx-client-0.9-8 (from the
> release)?  

Hi,

after downgrading to freenx-client-0.9-8, all nx connections now work perfectly.

--- Additional comment from orion.com on 2009-11-05 12:20:16 EST ---

Same problem on F-12 with 0.9-10.  How to fix there?

--- Additional comment from triage.org on 2010-04-28 05:45:02 EDT ---


This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from triage.org on 2010-06-28 10:07:23 EDT ---


Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.