I have been using OSXvnc 1.6 over SSH (with Chicken of the VNC as the client) for years to access my headless Mac Mini and it has been working fine. The Mini was put to sleep each night using the VNC connection, then woken, logged into using ssh, and reconnected using CotVNC. No problems, it worked great.
Recently I saw that Vine Server 2.2 had been released and installed it. All worked well except that when the Mini was woken from sleep the server rejected the attempt to connect by CotVNC over ssh. I figured that a bug had been introduced in the new release so tried going back to the one used previously after removing /Library/StartupItems/OSXvnc, and re-installing the older version as the startup item.
However the problem now continues. I tried removing the plist file in ~/Library/Preferences and re-setup all the settings, still no success.
Somehow Vine Server 2.2 has broken my older installation of OSXvnc, even though as far as I can tell I have removed all trace of 2.2. How can I get the old version working again? At present I have to reboot the Mini from the ssh command line each time it is woken, so each time all my setup is lost. That’s bad. The server is started automatically as part of the reboot and once the login screen appears it allows CotVNC to connect over ssh as normal. The only problem is waking from sleep.
Sooner or later I’m going to lose some important work as a result of forgetting to save it before sleeping the Mac. Please help!
I can’t say much about reverting back to 1.6. Removing the .app AND the /Library/StartupItems/OSXvnc folder should eliminate all traces.
As far as the problem in Vine Server 2.2 can you further describe what happens when trying to connect to it? How does it fail? How are you walking the computer from sleep?
The problem with Vine 2.2 was that when the Mini was woken and logged into using ssh, an attempt to connect using cotVNC resulted in the window being created followed immediately by a dialog sheet saying that the server had disconnected and offering the option to reconnect. Attempting to reconnect simply resulted in the same message being displayed.
I’m starting to wonder whether it may be something to do with the fact that the ssh being used to tunnel VNC at the time the Mini was put to sleep was not being exited cleanly - i.e. when the Mini was put to sleep via VNC (which it was), it was asleep before there was time to exit the ssh session. I wonder this because I did subsequently get the same message when trying to connect to the Mini while awake (I forget the exact leadup to this), and when exiting ssh and re-logging in it cleared the problem.
All this was never an issue previously though.
The Mini is normally woken from sleep using a network WOL packet (“Wake for administrator access”), though the other types of wakeup (Bluetooth activity, Apple Remote, pushing the power button…) give the same behaviour.
Solved: it seems that 2.2 changed the port setting to auto. Now it’s back at zero it all works again, including 2.2.
I am having similar problems. Using the latest server (2.2), using the boot-time System Server. When I put the mini to sleep and then wake it up (I use wake-on-lan packets), my VNC client (UltraVNC on XP) can no longer connect; it just seems to wait, and wait (saying "Negotiate Protocol Version) … eventually coming back with
Connection failed - Error reading Protocol Version
My settings are:
Connection: Display Auto (also tried 0, same results)
System: Allow Sleep, Swap mouse
Sharing: Advertise Bonjour, Allow only 1 connection (dropping previous one)
Start: Restart if terminates unexpectedly.
I use the “Start System Server” button.
For UltraVNC you will want to make sure to disable ZlibHextile support in order to connect. (You may have done this already)
The next time this occurs can you please do the following:[list]
On the Mac launch the program /Applications/Utilities/Activity Monitor.app
Double click the OSXvnc-server process in the list.
Click the Sample button
Save… the file and post it here as an attachment.
It appears from this log that the server process is actually being terminated by an external signal (not sure what).
Can you check and verify that “Restart server if it terminates unexpectedly” is ENABLED on the Vine Server->Startup tab.
I will check and report back. In the meanwhile … could starting up FrontRow while the server is running mess things up? This is a mac mini used for home theatre.
Can you check and verify that “Restart server if it terminates unexpectedly” is ENABLED on the Vine Server->Startup tab.[/quote]
It is ENABLED. I’m still having the problem. But now it appears that VNC does respond after waking up from a Sleep, eventually … it just takes anywhere from 3 minutes to 6 minutes to do so.
Any suggestions on how to debug this?