Bug 503822
| Summary: | Can't connect to freenx-server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt Castelein <matt.castelein> | ||||
| Component: | freenx-server | Assignee: | Axel Thimm <axel.thimm> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 11 | CC: | contact, gwync, sly.midnight | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 0.7.3-15.fc10 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-08-10 21:40:25 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 346321 [details]
connection log
I have managed to reproduce this. It occurs when connecting after a reboot.
the full messages are attached. (I have removed host and user names for security reasons)
Tried running nxnode --agent as a normal user and get a blank NX window and the following in the console: $ nxnode --agent NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.3.0) NX> 716 Starting NX Agent ... NXAGENT - Version 3.3.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '27650'. Session: Starting session at 'Mon Jun 8 11:20:35 2009'. Info: Using alpha channel in render extension. Info: Not using local device configuration changes. error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy Session: Session started at 'Mon Jun 8 11:20:47 2009'. Session: Terminating session at 'Mon Jun 8 11:20:54 2009'. Session: Session terminated at 'Mon Jun 8 11:20:54 2009'. FreeFontPath: FPE "/usr/share/X11/fonts/misc/" refcount is 2, should be 1; fixing. NX> 716 NX Agent exited with status: 0 NX> 1001 Bye. The only error I see here is "error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy".. /usr/X11R6 does not exist and I cannot find this SecurityPolicy anywhere else either, but it does not seem to stop the agent from starting.. However I am still unable to connect using a client. Still exists in freenx-server-0.7.3-12.fc11.x86_64.. Changing version to 11. Hello, I'm chiming in to say that my i386 (i586 kernel) install (upgrade rather) to F11 from F10 has caused freenx-server (from a Windows client) to fail utterly each and every time when trying to connect after successfully authenticating. After a very frustrating day spent trying to diagnose it, uninstalling, reinstalling, configuring from scratch and all of that...I finally saw an error message that suggests that a proper version of nxagent was not found for the currently installed version of freenx. I do not currently have a copy of the log file that said this, but when I do, I will upload it tomorrow. I have no idea why it would say that, but it leads me to believe that either the F11 package is broken or a missing dependency was not properly resolved. It was dumping a similar error as above immediately after the upgrade with the same config that worked in F10, as well as after I cleaned it up and reinstalled clean with an all new node.conf and public key setup. I am not using SElinux so that can be ruled out. Also, the only other thing to note is that I'm using the NoMachine client for Windows currently to log into my freenx-server running on Linux. Tomorrow I will post the exact logs and a copy of the exact error message. I just found out I had a copy of nx-3.3.0-33.fc10.i386 package still installed from my F10 installation. Apparently the upgrade to F11 and then a forced yum -y update did not catch that. I have since removed the offending package and will attempt to reinstall the F11 freenx packages and try again... Will post updates as I get more info. (In reply to comment #5) > I just found out I had a copy of nx-3.3.0-33.fc10.i386 package still installed > from my F10 installation. Apparently the upgrade to F11 and then a forced yum > -y update did not catch that. I have since removed the offending package and > will attempt to reinstall the F11 freenx packages and try again... > > Will post updates as I get more info. I hit that with yum upgrades, too. Once I removed nx, things were ok, and I could add it back afterward with no issues. It appears the older nx package was missed by yum on my system as well. I have updated the errant package, but I still cannot connect to nx. The session authenticates, then dies. I did the same thing, ran nxsetup --uninstall --purge and then nxsetup --clean --install and did the usual. After manually unlocking the 'nx' user as an error message suggested it needed the '-f' switch, a second run of the --install worked. However the connect still fails with the same error as above. When I manually run nxnode --agent, this is what I get: [serspecv04nismo@Voodoo9 ~]$ /usr/libexec/nx/nxnode --agent NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) NX> 716 Starting NX Agent ... NXAGENT - Version 3.2.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '20968'. Session: Starting session at 'Wed Jun 24 11:13:14 2009'. Info: Using alpha channel in render extension. nxagentCreateColormap: WARNING: Visual not found. Using default visual. /usr/libexec/nx/nxnode: line 1579: 20968 Floating point exceptionPATH="$PATH:$PATH_BIN" $PATH_BIN/nxagent -name "NX Agent Test - Args: $@" $@ NX> 716 NX Agent exited with status: 136 NX> 1001 Bye. This definitely suggests the freenx packages are broken as I suspected originally. Note the line that says "line 1579: 20968 Floating point exception..." what does that mean? Woah, wait a tick...I just fired it up again and suddenly it works...after an initial pissed off message as above. I will test through out the day including a reboot and all to make sure its not a fluke or to include quirks it may exhibit. Hmm, happy day, I guess... Ok, I have done some more testing. Immediately after a reboot, I cannot complete a successful connect. No matter how many times I try. However if I login via ssh and run nxnode --agent as the user, it fails. And I still cannot connect. However if I then proceed to run the command with root privileges and then connect, it works thereafter. There must be a bug somewhere in the code that prevents it from setting proper permissions on certain files when it acquires root privileges before dropping them. Here's what I did and the output, you can see the first time I ran the command after failing to connect, and where I ran the command again with root privileges where it then fixes whatever was broke: [serspecv04nismo@Voodoo9 ~]$ /usr/libexec/nx/nxnode --agent NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) NX> 716 Starting NX Agent ... _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 9 _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local NXAGENT - Version 3.2.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '4451'. Session: Starting session at 'Wed Jun 24 13:05:16 2009'. Error: Aborting session with 'Unable to open display '''. Session: Aborting session at 'Wed Jun 24 13:05:16 2009'. Session: Session aborted at 'Wed Jun 24 13:05:16 2009'. NX> 716 NX Agent exited with status: 1 NX> 1001 Bye. [serspecv04nismo@Voodoo9 ~]$ /usr/libexec/nx/nxnode --clean NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) ^C [serspecv04nismo@Voodoo9 ~]$ /usr/libexec/nx/nxnode --help NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) ^C [serspecv04nismo@Voodoo9 ~]$ /usr/libexec/nx/nxnode --agent NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) NX> 716 Starting NX Agent ... _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 9 _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local NXAGENT - Version 3.2.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '5327'. Session: Starting session at 'Wed Jun 24 13:06:32 2009'. Error: Aborting session with 'Unable to open display '''. Session: Aborting session at 'Wed Jun 24 13:06:32 2009'. Session: Session aborted at 'Wed Jun 24 13:06:32 2009'. NX> 716 NX Agent exited with status: 1 NX> 1001 Bye. [serspecv04nismo@Voodoo9 ~]$ sudo /usr/libexec/nx/nxnode --agent NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) NX> 716 Starting NX Agent ... NXAGENT - Version 3.2.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '6105'. Session: Starting session at 'Wed Jun 24 13:07:03 2009'. Error: Aborting session with 'Unable to open display '''. Session: Aborting session at 'Wed Jun 24 13:07:03 2009'. Session: Session aborted at 'Wed Jun 24 13:07:03 2009'. NX> 716 NX Agent exited with status: 1 NX> 1001 Bye. [serspecv04nismo@Voodoo9 ~]$ Yes, yes.. I have the same thing! $ /usr/libexec/nx/nxnode --agent NX> 1000 NXNODE - Version 3.2.0-73 OS (GPL, using backend: 3.2.0) NX> 716 Starting NX Agent ... _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. _XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 9 _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local NXAGENT - Version 3.2.0 Copyright (C) 2001, 2007 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '26215'. Session: Starting session at 'Wed Jun 24 13:33:48 2009'. Info: Using alpha channel in render extension. Info: Not using local device configuration changes. error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy Session: Session started at 'Wed Jun 24 13:34:00 2009'. Session: Terminating session at 'Wed Jun 24 13:34:15 2009'. Session: Session terminated at 'Wed Jun 24 13:34:15 2009'. FreeFontPath: FPE "/usr/share/X11/fonts/misc/" refcount is 2, should be 1; fixing. NX> 716 NX Agent exited with status: 0 NX> 1001 Bye. I can confirm what Reilly found. If I run nxnode again with root privileges, I can connect after that, until a reboot. Stupid question...but I just now noticed that the nx packages for Fedora 10 were based on NoMachine 3.3.x and now the ones in Fedora 11 are based on the 3.2.x versions...why? What's the reason for the downgrade? It could be that the problem we're suffering was fixed (or at least mostly mitigated) in the 3.3.x series. I'm just curious...I'm brain storming ideas on how to make freenx work with this broken release more reliably using a custom tweak to my box. But I would appreciate if the appropriate package maintainers checked this out. Thanks! Just adding something to this...while that trick gets me logged in...something else is wrong... If I disconnect (suspend) the session and later reconnect to it I can't load any programs. If I leave a konsole window open and issue a #firefox command for example...I get a 'Error: Cannot open display: 2000' type of message. I can then log out and open a new session and loading of programs works again, but again, if I disconnect and reconnect, I cannot load any new programs, just work with what's already open. Confirmed this same behavior on TWO (2) different machines, 1 running F11 and the other running F10. The only thing in common on these machines, is that they are both i386 machines (F11 running i586 kernel and the F10 machine running i686 kernel). Another F10 machine I have has a nearly flawless installation of freenx, but it is F10 x86-64...go figure. Reilly, I was not able to confirm the suspend/reconnect behavior you described. However, it sounds like you are using KDE and I am using Gnome. Perhaps there is a second issue at work? Anyway, I'm changing the platform on this bug since you're i386 and I'm x86_64. Just to reiterate, my x86-64 version on Fedora 10 works flawlessly, except for the original above described error always happening the first time you try to connect after a reboot. But the second and subsequent connect attempts always seem to work without having to do anything else other than reattempting the connection (until a reboot, then the first connect attempt immediately after the reboot fails with subsequent connects succeeding). Disconnecting/suspending of sessions also works perfectly in the x86-64 version on F10 for me. Its the 32bit F10/F11 that seemed to be giving me the most grief. I don't know if you wanna change the platform after that explanation or if you wanna just leave it be... P.S. That problem about not being able to load new programs with that 'cannot connect to display: 200X' error I get in the F11 KDE box, I also get on the F10 Gnome box I run. So it does not seem to matter if I run KDE or Gnome...its the disconnecting and reconnecting to a suspended session that causes me not to be able to load any new programs into the already running desktop...just continue to interact with what's already loaded. I believe "All" is still appropriate. Now if we could just get this bug some attention... I found this today: prelink: /usr/libexec/nx/nxagent: Could not find one of the dependencies prelink: /usr/libexec/nx/nxssh: Could not find one of the dependencies prelink: /usr/libexec/nx/nxproxy: Could not find one of the dependencies ..Yet RPM says the package is OK. ldd shows these files missing from nx:
libXcomp.so.3 => not found
libXcompext.so.3 => not found
libXcompshad.so.3 => not found
According to yum, these are provided by nx-3.2.0-32.fc11.x86_64, which is installed. I searched for the files and found them in /usr/lib64/nx/, which is I guess not in anybody's $PATH..
I put in a quick fix for this library issue, but it had no effect on the behaviour described in this bug. What's the status on this? Any word, I've been getting by relatively ok with no real problems to speak of since I started using the official nomachine nx binaries from www.nomachine.com. But those packages require totally different setup than the freenx one's and for a while I was almost going to scrap it because the official NoMachine packages don't allow for su based authentication (since I have ssh password authentication disabled and only use public key auth). I did figure out how to use their "alternative" authentication mechanism and all is ok...but just the same. I'd rather use a package that's in the repositories than third party files. (In reply to comment #22) I agree. I also have password auth disabled, and I would prefer to stick with packages in the repos if possible. It would be really great if someone could have a crack at this. It appears a new nx base package has been released to Fedora 10 x86-64. I will update with what I find. Going to need to uninstall the NoMachine packages on one of my 32bit i386 installs and test again after the update trickles down to them to see if the new "maintenance" update fixed anything. I do not have the NoMachine packages installed. I will test in my environment also. The new nx package does not have any effect on this bug on my system. How does this voting this work? I placed 1 vote and I see Matt placed 35 votes. I also see that it says I placed 1 vote out of 100 allowed, what does that mean? You ca(In reply to comment #27) > How does this voting this work? I placed 1 vote and I see Matt placed 35 > votes. I also see that it says I placed 1 vote out of 100 allowed, what does > that mean? You can distribute your 100 votes across as many or as few bug as you like, to indicate your interest in each. Help is located at https://bugzilla.redhat.com/page.cgi?id=voting.html (In reply to comment #14) > Stupid question...but I just now noticed that the nx packages for Fedora 10 > were based on NoMachine 3.3.x and now the ones in Fedora 11 are based on the > 3.2.x versions...why? What's the reason for the downgrade? It could be that > the problem we're suffering was fixed (or at least mostly mitigated) in the > 3.3.x series. nx 3.3 would not build on rawhide (to become F11), so there was no downgrade, but rather a delayed upgrade on rawhide. Let me summarize this report (or the parts that are still an issue) and please correct/add what is necessary: You are now using nx 3.3.0 on both F10 and F11, but the problem is only with F11, and you confirmed this to be still true with 3.3.0 (as until the 16th F11 had 3.2.0, while F10 had gone 3.3.0 already four months ago). The workaround is to run /usr/libexec/nx/nxnode --agent as root and then the server behaves sanely until the next reboot. There will be new freenx-server/client packages shortly which also may affect this bug. I am using nx-3.3.0-35.fc11.x86_64. I cannot speak for those using F10. Axel: this is the bug that led me to file bug 509907.. Because of the errors I saw (comment 19) I thought it might have something to do with the behavior described in this bug report. (In reply to comment #30) > The workaround is to run > > /usr/libexec/nx/nxnode --agent > > as root and then the server behaves sanely until the next reboot. > > There will be new freenx-server/client packages shortly which also may affect > this bug. The workaround I used was to run it with sudo, not directly as root. I will be glad to test the new packages when they are available. freenx-server-0.7.3-14.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/freenx-server-0.7.3-14.fc10 freenx-server-0.7.3-14.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/freenx-server-0.7.3-14.fc11 Looks good, I was able to connect. (In reply to comment #35) > Looks good, I was able to connect. That's great! Could you outline what you used on both sides? E.g. was this Fedora 11 on both sides and the latest freenx-server/-client packages? Another mix, other versions? Just trying to collect some info in case it doesn't fix all combinations. Thanks! (In reply to comment #36) > That's great! Could you outline what you used on both sides? E.g. was this > Fedora 11 on both sides and the latest freenx-server/-client packages? Another > mix, other versions? > > Just trying to collect some info in case it doesn't fix all combinations. > Thanks! It's Fedora 11 / freenx-server on the server side and the nomachine client / windows XP on the client side (my office) Just saw the latest updates to this thread over the weekend, this morning. I just uninstalled the nomachine nx packages and reinstalled the freenx Fedora 11 packages on a work machine and reconfigured it the way I had it before...same behavior...but I just noticed the latest packages yum pulled down this morning are still...freenx-server-0.7.3-12.fc11.i586 Is this to be expected, or do I have to do anything special to get the latest version mentioned in this thread? Reilly, I went and fetched them from koji (follow links from comment 33 and comment 34).. You can expect it will take a little while before these propagate out and show up in yum. Just to clarify, I used: rpm -Uvh http://kojipkgs.fedoraproject.org/packages/freenx-server/0.7.3/14.fc11/x86_64/freenx-server-0.7.3-14.fc11.x86_64.rpm ..Adjust as appropriate for your system. Oh thanks...I will give that a shot and post back my results. Just to clarify on my part as well...the machine I'm currently doing this testing on, is a 32bit Fedora 11 box. I have another machine at home (currently disconnected due to a recent move) that's regrettably still running 32bit Fedora 10 that *seemed* to be exhibiting the same behavior...I could be mistaken. The only box that doesn't really do this to me is a x64 Fedora 10 box I have at home that is currently setup and functioning properly (though all first attempts to connect after an reboot still fail, but work if you attempt to connect a second time without having to do anything). freenx-server-0.7.3-14.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update freenx-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8023 freenx-server-0.7.3-14.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update freenx-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8022 Ok, I just tested the freenx-server-0.7.3-14.fc11.i586 package after a clean reboot and it now acts like the one I have installed and running on my x86_64 F10 box. First connect after a reboot fails, with subsequent connects working, this is a major improvement. It also does not appear to exhibit the strange bug of when suspending the session and reconnecting to it later prevents you from launching any new programs (if done from an already open console window loading of new programs says something about not being able to connect to display some number, usually the active display number for the NX session). Looking good so far! Thanks! I need to test on my other i686 F10 box...and when I do I will post the results of that as well. On my system with this new package, I do not see the behavior described in comment 44 where the first connect fails. I am now able to connect reliably each time, even after a reboot. (In reply to comment #44) > Ok, I just tested the freenx-server-0.7.3-14.fc11.i586 package after a clean > reboot and it now acts like the one I have installed and running on my x86_64 > F10 box. First connect after a reboot fails, with subsequent connects working, > this is a major improvement. [...] (In reply to comment #45) > On my system with this new package, I do not see the behavior described in > comment 44 where the first connect fails. I am now able to connect reliably > each time, even after a reboot. Thanks for the feedback! Maybe the difference is in the client used? Matt uses the nomachine client - Reilly, what are you using? I'm using the NoMachine client from a Windows machine as well, if that makes a difference? (In reply to comment #47) > I'm using the NoMachine client from a Windows machine as well, if that makes a > difference? In that case, I guess I should specify I am using NoMachine's NX client for windows version 3.3.0-6 (In reply to comment #48) > (In reply to comment #47) > > I'm using the NoMachine client from a Windows machine as well, if that makes a > > difference? > > In that case, I guess I should specify I am using NoMachine's NX client for > windows version 3.3.0-6 Same version here actually...sorry I forgot to mention the version. I believe its still the current official version on NoMachine's website available for download. freenx-server-0.7.3-15.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update freenx-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8022 freenx-server-0.7.3-15.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update freenx-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8023 This update fixes the issue that no connection is possible with nx-client after reboot freenx-server-0.7.3-15.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. freenx-server-0.7.3-15.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. |
Occasionally when I attempt to log on via NX, the session will not connect. The log states: Can't open /var/lib/nxserver/db/running/sessionId{D11EB5795287B51FD437021359C7F24D}: No such file or directory. mv: NX> 1006 Session status: closed cannot stat `/var/lib/nxserver/db/running/sessionId{D11EB5795287B51FD437021359C7F24D}': No such file or directory NX> 1001 Bye. sometimes it works, sometimes not. Removing all the files from /var/lib/nxserver/db seems to help. The log suggests running /usr/libexec/nx/nxnode --agent but this did not seem to reveal anything of value. I am currently using freenx-server-0.7.3-11.fc10.x86_64.