We have a production machine running Suse 11 Enterprise Server x86_x64 with tigtvnc as the VNC server used to connect remotely via UltraVNC view on a Windows 7 machine.  Up to this point, the setup has worked wonderfully.  This machine is one of lesser accessed machines by one of my coworkers that prefers a GUI administration.  With that said, I am not sure when the problem started or what might have caused it.The first sign of the problem that was noticed was when trying to launch Konqueror.  It acts like it tries to start (as evident in the task bar) for a moment, then disappears and nothing ever launches.  The other problem is that when you go to add a widget, then entire X session greys out with the only option to end the VNC session.The real problem is when I try to kill the session via putty I get:server:/ # vncserver -kill :1Cant't find file /root/.vnc/server:1.pidYou'll have to kill Xvnc process manuallyAnd when I try to start it:server:/ # vnserver :1A VNC server is already running as :1Also tried this:server:/ # /sbin/service vncserver stopservice: no such service vncserverAnd using ps -A doesn't reveal anything VNC related (Xvnc, vncserver, etc. I'll post the process list if requested)What gives?  How do I kill this thing?  Since it's on a production machine, any restart request is a big bureaucratic process, so I am trying to avoid that as well.
Problems with tight vnc on Suse 11 enterprise x86_x64
linux;vnc;suse
I did manage to find how I was still able to connect:  In Yast, theres a Remote Administration section that allows you to enable to disable remote remote administration. This, seemingly, creates a port listening on 5900.  As far as the problems displaying the desktop, turns out KDE4 went under a major overhaul with their new desktop environment called plasma.  There was something about how plasma rendered the visuals that would cause vnc to quit displaying the desktop correctly (washed out grey/tan).The initial screen to appear was the login screen with various options across the bottom (language, enviroment, etc).  There was an option to switch to gnome, which I tried.  What I didn't notice was when the user name was entered, the option would switch when prompted for the password.  When swtiched right after entering the user name, it succeeded and was able to log in a gnome session without crashing.