Description of problem:Machine A is running vnc-server in FC7 and the screensaver is running under kde. Machine B running F8 makes a vnc connection via ssh tunnel to machine A. Machine B then disconnects from A. Now the screen no longer wakes up if the mouse on machine A is moved. The machine needs to be Version-Release number of selected component (if applicable):vnc-server-4.1.2-19.fc7 and vnc-4.1.2-23.fc8 How reproducible:Every time Steps to Reproduce: 1. Make vnc connection from F8 machine to FC7 machine via ssh tunnel 2. Do stuff and then disconnect from FC7 machine 3. FC7 machine no longer has its mouse active. Alt-Ctrl Backspace does not stop the X session, and Ctrl-Alt Fn does not work either. However if the vnc connection is re-established via an ssh tunnel it is seen that the kde desktop is still there on teh vnc-server machine as before, and work can be done via the vnc connection on the server machine. Actual results:Mouse and keyboard no longer active on the vnc-server machine. Expected results:Mouse and keyboard should remain active on the machine even if another user connects to it via vnc through an ssh tunnel. Additional info:No pertinent messages appear in the /var/log/messages file. Also this has been tested with different physical machines acting as A and B in the above description - all are yum updated to the present. It is the same for different screensavers running in the vnc-server machine. Additionally ssh'ing in and doing telinit 3, followed by telinit 5 does not fix the problem either and a re-boot is necessary.
Are you using Xvnc (= vncserver) or libvnc.so module to Xorg? Would it be possible tell me how you setup ssh tunnel, please? (ssh -X or -via parameter)
OK what I do is as follows: On the machine that acts as the vnc server I add a section in xorg.conf like: Section "Module" Load "vnc" EndSection and also in the "screen" section there is a password line added like: Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 24 Option "passwordFile" "/opt/local/etc/vnc/passwd" SubSection "Display" Viewport 0 0 Depth 24 Modes "1680x1050" "1280x1024" "1024x768" "800x600" EndSubSection EndSection That machine is booted to runlevel 5 and nothing further needed there. In the client machine I have entries in .ssh/config such as Host farend #next line when port forwarding for ssh changes from 22 to 23456 Port 23456 ForwardAgent yes Hostname farend.specialhost.co.uk LocalForward 55900 localhost:5900 So in one terminal window I then: ssh farend and this sets up the tunnel with port forwarding from local 55900 to remote 5900 Then I have a script which is run in a second terminal window that essentially does vncviewer -passwd ~/.vnc/passwd localhost:55900 Then this gives a vnc window to the server machine via the tunnel even if the remote user has not yet logged in provided X on the server is running. I hope this helps.
I have now tested this problem with new version vnc-server-4.1.2-19.3.fc7 and this version now also fixes the bug reported above. Once the new version is pushed to stable this bug can be closed also. Please also build for F8. Thanks Mike
(In reply to comment #3) > I have now tested this problem with new version vnc-server-4.1.2-19.3.fc7 and > this version now also fixes the bug reported above. Once the new version is > pushed to stable this bug can be closed also. Please also build for F8. Yes, fix is going to be included in next F8 update. Are you sure that new version solves problem? I wonder if yes.
Yes, certainly on my test (vnc-server) machine here running F7 the new version retains mouse control on that machine even if the client connects via vnc and then disconnects again, when the server had already gone into powersave mode. I checked three times and it gives normal operation after vnc'ing in and disconnecting - the machine running vnc-server still has normal mouse/keyboard response, and will come out of powersave mode in the same way as if there had not been any vnc activity. Until this new version that was not the case. So this new version seemed to have fixed this problem. I do have access to another machine which is running F7 also and I could try to test the new version of vnc-server there as well. I will test on that second machine and let you know the outcome.
I have now conducted tests on the second machine running vnc-server-4.1.2-19.3.fc7. The local user in that machine now retains mouse/keyboard function even if I vnc in whilst that machine is in powersave mode. I will test that machine again later this evening, but this does look like the problem reported in this bz is also resolved which is excellent given that the fix was done for a different bug! ( https://bugzilla.redhat.com/show_bug.cgi?id=430468 )
Interesting. Closing as duplicate of #430468 because it is same problem. Update will be available soon (vnc-4.1.2-20.fc7 and vnc-4.1.2-24.fc8) *** This bug has been marked as a duplicate of 430468 ***
I have tested this further - and it appears my earlier enthusiasm was misplaced. By leaving the vnc-server machine running for a much longer time, and then vnc-ing in then brings in the same symptoms as reported in the initial report of this bug. So the new version does not fix this issue and more work is needed for this. Sorry for writing in too early before - I clearly got too excited that it was fixed!
Sorry Adam but am re-opening this one.
I am wondering if there are any specific tests I can run which will provide more information about why this bug is occuring? There is nothing in /var/log/messages. I can run tests tomorrow and then after Monday if you can suggest specific things I may be able to do to get log files with something in them. Is there a way to get some backtraces which might help for example?
I would like to run vnc tests on two machines that I have that are both running F8 and are both in the same room, so that I can be the "local" user on both machines with one being vnc client and the other vnc-server. When the build for f8 has completed I will then be able to run any suggested tests in the evenings here on almost any day. Also is there any way to nail down whether this problem is purely vnc, or xorg - clearly this manifests itself when using vnc but is it possible this is throwing up an X problem? If you can suggest something I can do to help diagnose this I would be happy to help further as this bug has been there quite a while and I want to be able to help find where the problem is. The bz #430468 is definitely fixed even though this one is not.
I have run some additional tests for three different combinations of hardware, and find that the problem reported here is hardware dependent! I am running the vnc client machine with your new f8 version (vnc-4.1.2-24.fc8) and connecting to three different machines as vnc-server. The results in this case are as follows: Case 1) For the vnc-server machine with hardware profile: http://www.smolts.org/client/show/pub_21298b78-3386-45f0-8f1b-80fccf545429 and running vnc-server-4.1.2-19.3.fc7 This problem does not appear - although it was a problem when I first entered this bug report. The recent version of vnc-server does seem to have resolved it for this machine. Case 2) For the vnc-server machine with hardware profile: http://www.smolts.org/client/show/pub_d3106a99-890c-4da2-a911-d4f78b5cd818 and running vnc-server-4.1.2-24.fc8 This problem does not appear - though I did not test for this bug on this hardware until now. Case 3) However for the machine with hardware profile which I have to list below (since it gives errors connecting to the smolt server): OS: Fedora release 7 (Moonshine) Default run level: 5 Language: en_US.UTF-8 Platform: i686 BogoMIPS: 3201.10 CPU Vendor: AuthenticAMD CPU Model: Unknow CPU Type Number of CPUs: 1 CPU Speed: 1599 System Memory: 748 System Swap: 1004 Vendor: MICRO-STAR INTERNATIONAL CO., LTD System: MS-6378 Form factor: desktop Kernel: 2.6.23.15-80.fc7 SELinux Enabled: False SELinux Policy: targeted SELinux Enforce: Disabled Devices ================================= (4131:34048:4131:34048) pci, cyblafb, VIDEO, CyberBlade/i1 (None:None:None:None) platform, i8042, None, Platform Device (i8042) (None:None:None:None) platform, pcspkr, None, Platform Device (pcspkr) (None:None:None:None) scsi, sr, None, SCSI Device (None:None:None:None) input, Unknown, MOUSE, Macintosh mouse button emulation (None:None:None:None) scsi, sd, None, SCSI Device (4358:12376:4358:12376) pci, VIA 82xx Audio, AUDIO, VT82C686 AC97 Audio Controller (None:None:None:None) platform, Unknown, None, Platform Device (bluetooth) (None:None:None:None) input, Unknown, None, Sleep Button (CM) (None:None:None:None) input, Unknown, None, Power Button (CM) (None:None:None:None) input, Unknown, None, Power Button (FF) (4358:45330:0:0) pci, Unknown, OTHER, VT8361 [KLE133] AGP Bridge (4358:12344:2341:4660) pci, uhci_hcd, USB, VT82xxxxx UHCI USB 1.1 Controller (None:None:None:None) net, Unknown, NETWORK, Networking Interface (None:None:None:None) tty, Unknown, None, 16550A-compatible COM port (None:None:None:None) platform, Unknown, None, Platform Device (vesafb.0) (None:None:None:None) platform, serial8250, None, Platform Device (serial8250) (None:None:None:None) input, Unknown, None, PC Speaker (4358:1670:4358:0) pci, parport_pc, OTHER, VT82C686 [Apollo Super South] (4358:1393:4358:1393) pci, pata_via, IDE, VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (None:None:None:None) scsi_host, Unknown, None, SCSI Host Adapter (None:None:None:None) pnp, serial, None, 16550A-compatible COM port (None:None:None:None) serio, psmouse, None, i8042 AUX port (4358:12375:4358:12375) pci, Unknown, OTHER, VT82C686 [Apollo Super ACPI] (None:None:None:None) usb_device, Unknown, None, USB Raw Device Access (4358:12344:2341:4660) pci, uhci_hcd, USB, VT82xxxxx UHCI USB 1.1 Controller (None:None:None:None) input, Unknown, MOUSE, PS/2 Generic Mouse (None:None:None:None) usb_device, Unknown, None, USB Raw Device Access (4358:12562:0:0) pci, agpgart-via, OTHER, VT8361 [KLE133] Host Bridge (None:None:None:None) input, Unknown, KEYBOARD, AT Translated Set 2 keyboard (32902:4649:32902:80) pci, e100, NETWORK, 82557/8/9 [Ethernet Pro 100] (None:None:None:None) scsi_generic, Unknown, None, SCSI Generic Interface (None:None:None:None) platform, Unknown, None, Platform Device (floppy.0) (None:None:None:None) serio, atkbd, None, i8042 KBD port (None:None:None:None) scsi_host, Unknown, None, SCSI Host Adapter (None:None:None:None) pnp, i8042 kbd, None, IBM Enhanced (101/102-key, PS/2 mouse support) (None:None:None:None) pnp, i8042 aux, None, PS/2 Port for PS/2-style Mice (None:None:None:None) platform, via686a, None, Platform Device (via686a.24576) (None:None:None:None) scsi_generic, Unknown, None, SCSI Generic Interface Filesystem Information device mtpt type bsize frsize blocks bfree bavail file ffree favail =================================================================== /dev/root / ext3 4096 4096 2519727 1492832 1467261 1294336 1181671 1181671 /dev/sda8 /home ext3 4096 4096 4032159 1258176 1053348 2052288 1919541 1919541 and running vnc-server-4.1.2-19.3.fc7 This does give the problems listed at the start of this bug report. It is therefore possible that the bug will only manifest itself on specific machines and is likely to be absent on others. Therefore I wonder if there are other users who might be able to verify this behaviour apart from me? if not then I now only have one machine on which this appears to be a problem. What do you advise? If there are no reports to confirm this for other people's machines then maybe it is only the machine in case 3 above that has this problem in which case it may be better to close this bug as can't fix?
I still don't have enough time to look onto this one deeper. This might be driver problem but it looks like vnc problem for me. I'm going to try figure what's going on next week.
I ran another set of tests on the one machine (case 3 above) that was displaying the problem after installing the new vncserver.... with the stock version of vnc client on an f8 machine making the connection as client the problem did appear. However when I updated that client machine to run vnc-4.1.2-24.fc8 vnc-libs-4.1.2-24.fc8 and then connected to the problematic vnc server machine running vnc-server-4.1.2-19.3.fc7 then the problem went away! I don't understand why changing the client to your new version should make a difference but it seems to have done this for that case. I will check this again later today but this does look now that if both the machines concerned are running your new code that this resolves this bug. I am now in a position where all my client and server machines now behave perfectly well with all machines running your new versions (-24 in f8).
With -20 in f7 and -24 in F8 vnc/vnc-server has been stable without further problems.
After #15 I have not seen any further recurrence of the symptoms of this bug so I am closing it as fixed in the current release.