TL;DR: Don't use any of those, use X2Go.
I've used various different VNC servers and clients before, but I've never found them to be very useful. Most of the time the connection is too slow to get anything done. Recently, I found out about NoMachine NX, which has a bunch of really cool technology to make it actually reasonable to use your desktop machine over the internet. And, it runs over SSH, so you don't need to worry about opening up additional ports or encrypting everything.
My own use case was not terribly demanding; I want to access the computer on my desk (running Debian) from my laptop on the couch (running OS X), but I figured if NX works over the internet, it'll work even better over my local wireless network, right?
Unfortunately, NoMachine NX isn't free software. (Although some parts of it are.) Over the years several groups have tried to create an alternative server implementations, striving for compatibility with the NoMachine client software.
I first tried FreeNX, using Ubuntu packages on Debian. (I suppose that should have been a red flag: never use software compiled for Ubuntu on Debian, or vice versa. It's just asking for trouble.) It almost worked. I could connect, but then it would immediately crash. I spent hours trying anything I could to fix it, to no avail.
I tried using NoMachine NX Free, the free-of-charge version of NoMachine NX. It installed everything in weird locations on my machine and that made me angry. Also, I couldn't get it working.
I then tried going back to FreeNX, recompiling all the Ubuntu packages from source on a Debian box to rule out version incompatibilities (which was surprisingly difficult). It wasn't until I was half way through this that I discovered X2Go. The X2Go team maintains a lot of the packages used by FreeNX. Many of the underlying libraries are shared by the two products.
X2Go accomplishes everything that NoMachine NX does, except that it doesn't try for compatibility with the NoMachine NX Client; there is a separate X2Go client, with Windows, Linux and OS X support. That's a good thing, as it allows the X2Go project to control both the client and the server. And, it's packaged for Debian. I installed it and it just worked. Very simple.
So, long story short: use X2Go. Stay away from NoMachine NX, FreeNX, NeatX; they aren't worth your time.
Bits of miscellany, (hopefully) indexed for the world! All opinions are my own, and not those of my employer.
Saturday, September 29, 2012
Monday, January 9, 2012
Shutting worker threads down gracefully after a signal in Python
Recently I wrote about a bug in Python around handling of signals in multi-threaded programs. The upstream Python developers suggested that in order to properly handle signals in multi-threaded programs across several operating systems, developers should use some of the newer APIs in the signal library to make sure we get the behavior we want.
A common scenario for threads and signals is a daemon with long running worker threads that need to exit gracefully when SIGTERM or some other signal is received. The basic idea is:
The challenge is to write the simplest code that will do this portably, (at least) on FreeBSD and Linux, and that requires absolutely no CPU in the main thread while waiting (we want to be able to sleep completely, not have to wake up periodically to check for signals).
This is the best solution I've come up with (skip down to the bottom, it's where the interesting stuff is):
Basically, we have to use set_wakeup_fd() to ensure that we can reliably wake up when a signal is delivered. The obvious function to use here (signal.pause()) doesn't work
A common scenario for threads and signals is a daemon with long running worker threads that need to exit gracefully when SIGTERM or some other signal is received. The basic idea is:
- Set up signal handlers
- Spawn worker threads
- Wait for SIGINT, and wake up immediately when it is received
- Shutdown workers gracefully
The challenge is to write the simplest code that will do this portably, (at least) on FreeBSD and Linux, and that requires absolutely no CPU in the main thread while waiting (we want to be able to sleep completely, not have to wake up periodically to check for signals).
This is the best solution I've come up with (skip down to the bottom, it's where the interesting stuff is):
import errno import fcntl import os import signal import threading NUM_THREADS = 2 _shutdown = False class Worker(threading.Thread): def __init__(self, *args, **kwargs): threading.Thread.__init__(self, *args, **kwargs) self._stop_event = threading.Event() def run(self): # Do something. while not self._stop_event.isSet(): print 'hi from %s' % (self.getName(),) self._stop_event.wait(10) def shutdown(self): self._stop_event.set() print 'shutdown %s' % (self.getName(),) self.join() def sig_handler(signum, frame): print 'handled' global _shutdown _shutdown = True if __name__ == '__main__': # Set up signal handling. pipe_r, pipe_w = os.pipe() flags = fcntl.fcntl(pipe_w, fcntl.F_GETFL, 0) flags |= os.O_NONBLOCK flags = fcntl.fcntl(pipe_w, fcntl.F_SETFL, flags) signal.set_wakeup_fd(pipe_w) signal.signal(signal.SIGTERM, sig_handler) # Start worker threads. workers = [Worker() for i in xrange(NUM_THREADS)] for worker in workers: worker.start() # Sleep until woken by a signal. while not _shutdown: while True: try: os.read(pipe_r, 1) break except OSError, e: if e.errno != errno.EINTR: raise # Shutdown work threads gracefully. for worker in workers: worker.shutdown()
Basically, we have to use set_wakeup_fd() to ensure that we can reliably wake up when a signal is delivered. The obvious function to use here (signal.pause()) doesn't work
Subscribe to:
Posts (Atom)
Using Cloudflare Access to Protect Home Assistant
In my last post, I mentioned how I've been using Cloudflare Access to secure my Home Assistant server. If you're not familiar wit...
-
TL;DR: Don't use any of those, use X2Go . I've used various different VNC servers and clients before, but I've never found the...
-
In my last post, I mentioned how I've been using Cloudflare Access to secure my Home Assistant server. If you're not familiar wit...
-
I've been using Home Assistant for several years. It's really great to be able to control all of our devices from a single place, ...