VNC on Suse 11.3

I’m not familiar with VNC on Suse, but I have been trying to get it setup correctly for a while now. I have enabled it in Yast and used the steps in this guide in an attempt to enable it: TightVNC (VNC Xvnc) on openSUSE as Client or Server (Remote Desktop Connections)

I always get a connection refused when trying to use the view to connect to it. The closest thing I have gotten is a black screen in the VNC viewer.

Any help is appreciated. Thank You.

This thread might help you out.
OpenSuse 11.3 VNC Black Screen /w Cursor then Timeout

Let’s check a few things. Please run these few commands to get data about your setup and post the results back here:

  • cat /etc/SuSE-release
  • rpm -qa | grep vnc
  • cat /home/abcdef/.vnc/xstartup
  • ls -l /home/abcdef/.vnc

In the last two, put your Linux username in place of abcdef.

  • and what desktop are you using, Gnome or KDE?

So I’ve been fighting with this black screen for a while now, and figured it was time to ask for some help. I followed the above mentioned tutorial only to get a black screen when trying to connect to vnc server, both from server itself and from another linux/windows client. Output from requested commands below.

rnorthcott@RN-Server-IST:~> rpm -qa | grep vnc
xorg-x11-Xvnc-7.5_1.8.0-10.3.1.i586
tightvnc-1.3.9-110.1.i586
libgtk-vnc-1_0-0-0.3.10-3.1.i586

rnorthcott@RN-Server-IST:~> cat /etc/SuSE-release
openSUSE 11.3 (i586)
VERSION = 11.3

#!/bin/sh

xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
gnome &
rnorthcott@RN-Server-IST:~> ls -l /home/rnorthcott/.vnc
total 16
-rw------- 1 rnorthcott users 16 2010-10-05 17:07 passwd
-rw-r–r-- 1 rnorthcott users 1115 2010-10-05 17:07 RN-Server-IST:5.log
-rw-r–r-- 1 rnorthcott users 6 2010-10-05 17:07 RN-Server-IST:5.pid
-rwxr-xr-x 1 rnorthcott users 126 2010-10-05 17:36 xstartup

I’ve been playing with this so much I’m a little concerned I may have made it worse… anyhow any help that could be provided would be greatly appreciated. btw I’m using gnome for desktop

Try changing the contents of xstartup to this:

#!/bin/sh

#xrdb $HOME/.Xresources
#xsetroot -solid grey
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &

/usr/bin/gnome &

No change. Any other suggestions?

so I think I may have figured it out. It seems that my issue was that I wasn’t setting up the desktops with dbus-launch. As soon as I ran dbus-launch vncserver :6 -geometry 1024x768 -depth 16 it worked

It also seems like it will work with any server arguments

Not totally sure what the difference is, but that seems to have been my solution…

The need for dbus-launch commenced with the arrival of openSUSE 11.0. There’s a bug report in the system, but it doesn’t have any traction. For the tweaks to get vnc going see this tutorial: TightVNC (VNC Xvnc) on openSUSE as Client or Server (Remote Desktop Connections)

I’ve just tried setting up vncserver and client as described in Swerdna’s tutorial but am experiencing a few strange things.
I configured the server on a laptop running oS11.3 with kde4.4.4 and set it to serve the kde desktop with the following code

#!/bin/sh
/usr/bin/startkde

My problems are:

  1. Starting the server with dbus-launch vncserver starts the server fine but a few seconds later I hear the login chime play and get notified by kopete that another user has just logged into the same msn account. Why is there a user logging into the system as soon as the vncserver starts?
  2. I set up vncserver to run as a service exactly as described in the tutorial but it isn’t working. The server doesn’t seem to get started. Any ideas? Are there any special permissions I need to apply?

Some additional questions.
After I’m finished with accessing the pc remotely, does one just close the vncviewer window or should one log out of the session in some specific way?

Do you have kopete set to start and connect when you login normally (i.e. locally) to the remote machine?

  1. I set up vncserver to run as a service exactly as described in the tutorial but it isn’t working. The server doesn’t seem to get started. Any ideas? Are there any special permissions I need to apply?
  • Please paste here the contents of the file vncserver.sh
  • and run this command from a console window and paste here the return that you get:
vncserver.sh
  • and this command too, substituting your real username for “name”:
ls -l /home/name/bin

Some additional questions.
After I’m finished with accessing the pc remotely, does one just close the vncviewer window or should one log out of the session in some specific way?

  • If you want to leave the vncserver running so you can log on remotely later on, then log out of the remote screen using the normal logout method (button → leave → logout)
  • If you want to close the session and turn off the vncserver simultaneously, open a console and run this command on the remote machine:
vncserver -kill :1

Yes Kopete is set to start and login automatically after login to the system on both the local and remote machines. When the vncserver starts does it immediately start a new session in the background so that you have two sessions running with the same user?

I have now managed to get the vncserver to start as a service thanks. Not sure what I did now to get it working though.

When I log out of the remote desktop as you suggest (by leave>logout) I’m presented with a black screen which I then do F8>Quit viewer. However, after doing this I can no longer log back into the remote machine and just get the dreaded blank black screen.

Just to add to my previous post.
I have discovered that although I can no longer connect to the remote PC again after logging out of a session I can reconnect on port 1

vncviewer 192.168.1.15:1

instead of

vncviewer 192.168.1.15:6

which presents me with the kde login screen that is seen after booting up. This is strange because the server is set to start on port 6 with

#!/bin/sh
rm /tmp/.X11-unix/X*
dbus-launch vncserver :6

so why is it allowing a connection on port 1?

It looks like you have experimentally started various instances of the vncserver which still run, and maybe some old lock files are hanging about. You should re-zero the situation by rebooting to cancel all the old instances of running servers. And empty the folder /tmp/.X11-unix of any (lost) lock files X1, X2 , X3… etc (but keep X0).

Then try again: see when you log out of the remote :6 screen, see whether you can again log onto a :1 screen. If you can, then there is a misconfiguration somewhere.

I too thought that there must be another instance of vncserver running but could find no trace of one.

This is what I have done:
Reboot and checked there were no lock files. Can confirm only X0 exists in folder /tmp/.X11-unix/
No running vncservers confirmed by checking ~/.vnc. There are no pid files. Also checking system activity (Ctrl + Esc) shows no vnc processes.

I’m satisfied that there are no instances of vncserver running. I then issue the command

dbus-launch vncserver :6

from the console and get confirmation that vncserver has started.

dbus-launch vncserver :6

New 'X' desktop is suntp002:6

Starting applications specified in /home/Kika/.vnc/xstartup
Log file is /home/Kika/.vnc/suntp002:6.log

Here is the log file immediately after starting vncserver. There are quite a few errors in that log. I’m not sure if that’s normal or not. To me it looks like it’s attempting to load up the full kwin and kde desktop.

Here is the xstartup file contents

#!/bin/sh

/usr/bin/startkde

After starting vncserver I checked to make sure there was only one instance running which there was. Checked by looking to see if only one lock file existed (X6) and only one pid file (suntp002:6.pid) in ~/.vnc existed.

After I have logged out of the remote screen (screen :6) and attempt to log in again onto screen :6 , I get a black blank screen but I can log in on screen :1. I also note that when logging in on screen :1, that I’m presented with the KDE login screen and not the KDe desktop like I would when logging in on screen :6. You say there may be a configuration issue but what other configuration files are there for vnc?

In Yast under Network Services>Remote Administration (VNC) I have Allow remote administration selected and open port in firewall selected. I have not configured the Krfb (K remote desktop sharing) app so I don’t think that is interfering.

I also note that for each additional vncserver instance I start (i.e. :2, :3, :4, etc) I get the login chime.

I have also observed that after starting the vncserver that there many duplicate processes running. Is that normal?
http://i198.photobucket.com/albums/aa111/sklipikish/openSUSE/th_399c8b8e.png](http://i198.photobucket.com/albums/aa111/sklipikish/openSUSE/399c8b8e.png)

Aha! Remote Admin VNC is intruding! The instance of VNC that is started in Yast → Net Services is a xinetd-based instance that doesn’t work in openSUSE 11.3. It attempts to serve a 1024x768 screen on channel :1 but often fails when the login is attempted. It will interfere with the instance that you run with “dbus-launch”.

Turn off the Yast → Network Services → remote Admin instance of VNC and reboot, then see if you can log off and then back on with only the dbus-launch version running.

OK, I disabled the Yast → Network Services → remote Admin instance of VNC and rebooted. Still cannot log back in on screen :6 after logging out of a session. Also, I still get the login chime sounding after starting the server and the kopete notification about logging in twice into MSN. Are those errors in the log normal? Here is what is added to the log when I login and logout and try log in again and get the black screen.

On another track, is it possible to connect to the current desktop on the remote PC, i.e. the one that is being used by the remote user locally? I ask as sometimes it would be useful for the local user at the remote machine to watch what I’m doing while accessing their PC so they can help themselves the next time.

I too am unable to re-connect if I log out. It used to allw a new login, but parhaps a bug has developed between openSUSE 11.2 and 11.3. Workaround: if you just kill/close the window on the client you can re-connect later from the client; you will then be protected from hacking by the VNC login password but not by the openSUSE login screen.

You can (and should) submit a bug report on this defect.

Regarding the connection to the same desktop: not with tightvnc. There’s another version that allows the same desktop, x11vnc, check it out on the internet: x11vnc: a VNC server for real X displays
It’s in our repos as an RPM

OK, I’ll look into submitting a bug report.

Can you confirm that it’s normal that a complete kde desktop is started in the background when starting the vncserver? Is it normal to hear the kde login chime when the server starts or for apps like kopete to start and auto log in?

I’ll check the x11vnc server out too.

suse tpx60s wrote:

>
> swerdna;2236447 Wrote:
>> You can (and should) submit a bug report on this defect.
> OK, I’ll look into submitting a bug report.
>
> Can you confirm that it’s normal that a complete kde desktop is started
> in the background when starting the vncserver? Is it normal to hear the
> kde login chime when the server starts or for apps like kopete to start
> and auto log in?
>
> I’ll check the x11vnc server out too.

I’m pretty sure that vncserver starts a full kde/gnome/etc. session which
runs as long as the server instance is up. My observation has been
(tightvnc) that if I lose a connections - or simply choose “disconnect”
under KRDC - while a program is running, the sucker will still be chugging
along when I connect again. Under 11.1, that was quite handy as KRDC had a
bad habit of going titsup at inconvenient times so I specifically checked
for the behavior when I went to 11.3.

I’m missing something here, I think. Using KRDC as the client, I have not
seen any issue with re-connects but I do not use the logout/shutdown options
and simply disconnect via KRDC. That doesn’t appear to cause any problem as
I can either go to another machine or use the original one and re-connect
with no problem. I usually login with ssh, launch vncserver then kill
vncserver via ssh when I’m done but that’s mainly a question of loading some
of the older machines I log into. On the bigger boxes with plenty of
resources I do leave the vncserver up on a guest account for some of the
other users but that one is pretty well locked down. I haven’t had any
complaints about it working and 3-4 users regularly use it.


Will Honea