Xpra failing on localhost

If you know Xpra then you know you can access a "background" X session remotely. It's reasonable to assume that you may also want to access it locally from time to time.

On Ubuntu Precise I was finding that attempting to access the local session failed silently. I have been using:

$ xpra attach -z0 ssh:user@localhost:99

This produces no output. The server log isn't very forthcoming either:

New connection received
Handshake complete; enabling connection
encoding set to rgb24, client supports ['rgb24', 'jpeg', 'png'], server supports ['rgb24', 'jpeg', 'png']
Unhandled error while processing packet from peer
Traceback (most recent call last):
  File "/usr/lib/xpra/xpra/protocol.py", line 338, in _process_packet
    self._process_packet_cb(self, decoded)
  File "/usr/lib/xpra/xpra/server.py", line 1957, in process_packet
    self._packet_handlers[packet_type](self, proto, packet)
  File "/usr/lib/xpra/xpra/server.py", line 1371, in _process_hello
    f = open(mmap_file, "r+b")
IOError: [Errno 13] Permission denied: '/tmp/xpra.QGv7UA.mmap'
connection lost: empty marker in read queue
Connection lost

The clue is in the .mmap. The server needs to be started with the --no-mmap option.

From the man page:

       --no-mmap
              Disables memory mapped pixel data transfer.  By default it is normally  enabled  automatically
              if  the  server  and  the client reside on the same filesystem namespace.

All good!

Start the Android media scanner from the command line

If you're like me, and let's hope for your sake that you're not, you find it much easier to run an SSH server on your Android device than using something like adb or USB Mass Storage or any of the other crap out there.

With SSH I can simply and easily check logcat, netstat, issue commands, copy files and generally bugger about.

Sometimes you have moved quite a lot of files around and you need your media scanner to launch to update its database. This can be done via the CLI.

Putting Windows XP to sleep remotely

Have you noticed that when connected to Windows XP via RDP that the Start Menu option for putting the machine to sleep vanishes? What the Hell is that all about?

It doesn't even make sense when you can wake the machine with Wake-on-LAN to reconnect if you need to. Saving energy not really a priority here.

To make things worse the Task Manager's menus have Standby and Hibernate disabled too.

You could mess about installing VNC, but why bother? Turns out the solution is incredibly easy!

Open a command prompt and enter:

 C:\> rundll32 powrprof.dll,SetSuspendState

That's it! The computer will enter Suspend.

If you're looking to hibernate the machine instead then:

 C:\> rundll32 powrprof.dll,SetSuspendState Hibernate

Job's a good un.

Now go install Linux.