Description of problem:F7 machine is rebooted by remote login. After machine reboots a remote login via ssh is started, and then using vnc the user session is logged in to KDE. A short time later the vncserver crashes and X on the server crashes also giving a kdm login screen again. Version-Release number of selected component (if applicable):vnc-server-4.1.2-19.fc7 How reproducible:Every time Steps to Reproduce: 1. Reboot machine 2. Login to F7 machine via ssh and set up port forwarding for vnc 3. Start vnc connection via ssh tunnel from F8 client 4. Client machine has the F7 server machine login screen on its monitor 5. Now enter login information and enter. Actual results: Login starts but shortly afterwards the vncserver crashes, and crashes Expected results: Login should continue, X should remain working, vnc should remain working. Additional info:Server machine is running fully updated F7, with kdm and the kde desktop. Client machine is running fully updates F8 with kdm and KDE desktop. /var/log/messages on the server machine has lines: Jan 28 10:24:40 physics30 kdm[2492]: X server for display :0 terminated unexpectedly Jan 28 10:24:43 physics30 setroubleshoot: [program.ERROR] exception RuntimeError: could not open display Traceback (most recent call last): File "/usr/bin/sealert", line 766, in <module> from setroublesho ot.gui_utils import * File "/usr/lib/python2.5/site-packages/setroubleshoot/gui_utils.py", line 26, in <module> import gtk File "/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py", line 76, in <m odule> _init() File "/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py", line 64, in _init _gtk.init_check() RuntimeError: could not open display I will attach /var/log/kdm.log shortly
Created attachment 293143 [details] kdm.log on server
Just to be clear (since the line for "Actual results" was truncated above) when this problem appears then X crashes on the server, and the vnc connection is abruptly terminated.
Additionally - I should also say that if the login to the user kde desktop is done at the server machine only then the login is successful and one can then vnc in to the session perfectly normally. Also if the vnc connection is made to the server machine, and then the login is initiated, but the vnc connection is closed immediately and before the login completes, then the login to the user on the server machine does complete normally, and connecting to that kde session via vnc works fine.... It is only when the login is initiated via the vnc connection and then allowed to proceed that the vnc session is abruptly terminated, and X on the server crashes.
libvnc.so module is badly broken now. I recommend you start using vino or krfb utilities to export your desktop through vnc before libvnc module gets fixed.
OK I will await libvnc.so being fixed. By the way is baracuda likely to be the replacement for vnc in F9, or would it likely be installed in parallel with vnc? (Noted that there is a review request at https://bugzilla.redhat.com/show_bug.cgi?id=430653)
Baracuda is going to be replacement for vnc. Our vnc has already too much patches and upstream doesn't care about that. Baracuda should be benefit for all
That sounds good. Will there be backports of baracuda to F8/F7 once the version for F9 is working? I looked briefly into vino and krfb, but I believe they depend on the user already being logged in on the server machine. I load the vnc module in xorg.conf, and then make the vnc connection via an ssh tunnel, so I can log the user in to the server machine desktop myself. I don't believe this is possible with vino or krfb? So I will cope with the existing vnc setup until libvnc.so gets fixed. Ultimately I will upgrade to F9 on all machines but that will of course be some months from now.
(In reply to comment #7) > That sounds good. Will there be backports of baracuda to F8/F7 once the version > for F9 is working? I looked briefly into vino and krfb, but I believe they > depend on the user already being logged in on the server machine. I load the > vnc module in xorg.conf, and then make the vnc connection via an ssh tunnel, so > I can log the user in to the server machine desktop myself. I don't believe > this is possible with vino or krfb? Yes, krfb and vino needs active session > > So I will cope with the existing vnc setup until libvnc.so gets fixed. > Ultimately I will upgrade to F9 on all machines but that will of course be some > months from now. I'm ready to backport anything but firstly I have to find where problem is :)
Would it be possible test proposed update, please? Let me know if you need build for other distro than F7. http://koji.fedoraproject.org/koji/taskinfo?taskID=515235
OK Adam I will test it but it may be a day or two before I get the chance to load the new version.
I see that currently it is still building (15.38UTC 13th March 08)- so when the build is complete I hope I will get a chance to test it tomorrow and will report back with the result after the test.
This isn't have to be tested immediately :) Btw build should be completed now (from koji - Completed Thu, 13 Mar 2008 15:15:08 UTC, build http://koji.fedoraproject.org/koji/taskinfo?taskID=515235)
I decided to test immediately - so used "rpm -Uvh" on the new rpm files in the f7 server machine. The rpm files I used were: vnc-libs-4.1.2-19.1.fc7.i386.rpm vnc-server-4.1.2-19.1.fc7.i386.rpm vnc-4.1.2-19.1.fc7.i386.rpm I noticed that even though the rpm files have fc7 in their name this gave on the f7 machine .fc8 extensions when doing "rpm -q" on the newly installed vnc versions!! vnc-server-4.1.2-23.fc8 vnc-4.1.2-23.fc8 vnc-libs-4.1.2-23.fc8 I re-booted the f7 vnc server machine but unfortunately the symptoms reported in this bz are still there with the new versions of the files listed here. I presume that installing these on the f7 server machine should still have worked ok? Or should I have also installed in the f8 client?
Oh no - I was in the wrong terminal when looking at the versions.... On the f7 machine the new files were indeed correctly installed as f7 versions: Doing rpm -q in the correct terminal window for the remote machine gave: [mike@physics30 ~]$ rpm -qa|grep vnc vnc-4.1.2-19.1.fc7 vnc-server-4.1.2-19.1.fc7 vnc-libs-4.1.2-19.1.fc7 However my report that these new version give the same symptoms as in the original report remains the same. Mike
Adam Could you build for f8 please? I would like to run your new version on my f8 client as well as having put your new version in the f7 server. Is it possible that the client machine is causing the problem and not the server machine? Either way if I install your new version in my f8 client I can test this.
this is server issue. Updated client cannot help you. Finally I reproduced this problem so give me some more time for debugging ;)
OK - I am ready to test any new version whenever you can build a new one for testing.
Would it be possible test next build, please? http://koji.fedoraproject.org/koji/taskinfo?taskID=520555
OK, I will test this build tomorrow (19th March) as I am away from where the test machines are today. I'll report back when I have tested this for you.
Excellent work Adam - version vnc-server-4.1.2-19.3.fc7 and related library does resolve this bug. I had no further crash or breakage of the vnc window. I will conduct further tests on the effect of the screensaver/powersave relating to another bz report concerning vnc but this version works well concerning the crash reported above. If my extended testing today shows no further problems I will close this bug later today.
(In reply to comment #20) > If my extended testing today shows no further problems I will close this bug > later today. Thanks for positive feedback. You don't have to close this bug. Update system closing bugs automatically when fix goes to the stable.
After further testing I am now satisfied that this bug is resolved with vnc-server-4.1.2-19.3.fc7 so I hope this version can be pushed to stable soon. By the way it would be nice if you can do a build for F8 with these fixes? Thanks Mike
By the way this new version also resolves https://bugzilla.redhat.com/show_bug.cgi?id=436318
vnc-4.1.2-20.fc7 has been submitted as an update for Fedora 7
*** Bug 436318 has been marked as a duplicate of this bug. ***
vnc-4.1.2-20.fc7 has been pushed to the Fedora 7 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 vnc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F7/FEDORA-2008-2640
If you want to install the new version of vnc server you need to separately run yum --enablerepo=updates-testing update vnc-server
vnc-4.1.2-20.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Excellent work - since running this version it has been free of problems, and with -24 in f8 it has also been stable.