My setup consists of Mac OS X system that runs RealVNC client to connect to Ubuntu Server machine, a KVM host, via VNC.
When working in a guest VM console over VNC you may end up clicking into the black area. Which grabs and locks your mouse pointer.
Actually, you don’t have to click the VM console screen area, if all you want to do is type in something. However, if you must use mouse to click something inside the terminal view it’s going to get locked.
To release your mouse pointer, normally you’d press Ctrl_L+Alt_L, as it is stated in the window title.
However, it doesn’t work on Mac. Instead you need to use:
PS: Interestingly, it is one of the top posts on this blog. I find it ironic. Apparently, way too many people run into this problem. If you’re one of them let me know in the comments section down below.
This is just an observation I made a couple of days ago. I had my new Macbook Air 11″ on for some 13hrs during which all I did was light use of Google Chrome to look up things once in a while, chat with people in Skype and Adium, listen to radio streams in iTunes, work in a terminal, of course, had Mail.app running which is configured not to save anything to disk, and by the end of the day Activity Monitor reported some 5GB worth of disk writes. 5 gigs, really?
Why would I be concerned? Well, I’m generally speaking curious, but also there’s a legitimate concern because SSD drives, which are of MLC type in Macbook Air’s, on average are guaranteed to last 5 years with average 40GB disk writes per day. So, you can see that 5GBs per day in that context isn’t really a small number.
So, I set out to figure out to see distribution of those disk writes but I haven’t found a solution yet. dtrace looks like the tool that could pull out this data but it falls short of showing accumulated values over time. What I’m talking about is Linux equivalent of iotop -o -a, which is just amazing, simple and user-friendly compared to dtrace.
Which reminds me to say that Mac OS X is a funny OS. It makes it really easy to use a computer in GUI department, but Apple seems to have applied their philosophy of radically simplifying things to command line applications as well. Less of output (otherwise useful and detailed) seems to be characteristic of Apple’s version of such tools as iotop and sar, to name a few.
This I find a little frustrating and limiting. By and large, though, I really like Mac OS X and the whole experience of running Macbook Air.
I’d highly recommend it.
I was doing a routine task – preparing a new CentOS server – today and ran into quite obscure problem.
I was at the point where I needed to configure VPN link but OpenVPN wouldn’t let me daemonize itself. It complained in the logs basically saying that the problem was this:
openvpn: daemon() failed: No such device (errno=19)
That’s weird. After an hour of troubleshooting this issue on the server I took it to #email@example.com where dazo, the channel operator, pointed out that some people previously had have a similarly looking problem, and that if /dev/null was involved it might be a similar or exactly that kind of problem.
I checked /dev/null with stat utility and it was indeed just a regular file. WHOA. This is a production server that doesn’t see software updates, tested and works for the most part as a clock. Utterly inexplicable at this point to me but I don’t have time to research this right now. I just wanted to make a post about it to remember to look into this later, because this is quite interesting and doesn’t happen very often. In fact, I’ve been working with Linux for at least 5 years now, and I’ve never seen anything of the sort. Not even my more than I am experienced colleagues.
There are many ways to do it depending on your context, i.e. whether you’re working with headless setup that doesn’t need to run X server – plain old console – or with an X-based setup.
In my particular case I had a CentOS box that ran without X server and experienced some obscure, intermittent lockups. So, I needed to hook up the display, hoping to see some output like kernel call trace or maybe some error messages the box locks up the next time. The problem was that the system would dim the screen and when the box locked up I couldn’t see anything that might had been printed on stdout.
After quite a prolonged session of error and trial, what I learned was that simply issuing setterm -blank 0 in a terminal over ssh session (didn’t try to directly enter this command, let me know if this works for you) wasn’t working. So, what I ended up doing was adding
% echo “/usr/bin/setterm -blank 0” >> /etc/rc.local
to the end of /etc/rc.local and rebooting the box.
That did it for me (finally! lol)