Red Hat Bugzilla – Bug 430468
vncserver crashes when remote login attempted from F8 machine
Last modified: 2013-04-30 19:38:43 EDT
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.
Login starts but shortly afterwards the vncserver crashes, and crashes
Expected results: Login should continue, X should remain working, vnc should
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: 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
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
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
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:
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!!
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
However my report that these new version give the same symptoms as in the
original report remains the same.
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
Would it be possible test next build, please?
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
(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?
By the way this new version also resolves
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.