John Smith's Blog

TL; DR: try adding the host name to /etc/hosts

For various reasons I can't be bothered to go into now, on an intermittent basis I end up doing a lot of development on Linux VMs on Windows - mostly Fedora on VMWare. For a while I've noticed that emacs (my editor of choice for the past 20+ years) has been intermittently very slow to start up - 10 seconds plus, I'd guess - taking much longer than a programs I'd assume to be much more hefty, such as web browsers or GIMP. Although I've got a few modes and other customizations in place, I wasn't aware that my emacs configuration was anything unusual, and it ran fine on "native" hardware that was much slower or lacking in RAM than my VMs.

Anyway, I finally decided to get off my backside and find out what the problem was, and ideally fix it... Googling for variants of emacs vmware slow startup failed to find anything useful - which is my main motivation for writing this up.

The first thing I tried was some basic profiling of the startup, as per tip #5 found here. This wasn't of any help though, telling me that .emacs was loaded in 0 seconds, which might have been reasonably true, but certainly wasn't anything like the real-world time between entering emacs myfile.txt and an editor window popping up.

Next thing I tried was a tip from an Ubuntu forum, but again this had no noticeable effect. I was about to try compiling all my .el files to be .elcs, but then it struck me that it might be worth trying a different angle of attack...

It's been quite a while since I last used strace, or similar tools such as , truss, etc - and certainly I've rarely used it on programs that I haven't written the original source code for. However, if this showed the process hanging on a particular system call, then that would certainly go a long way to understanding what was happening.

Unfortunately, I don't have the output to cut'n'paste here, but it was immediately apparent that something related to the hostname could be the cause - the process was hanging on poll() calls, and a couple of lines further up in the logging were references to the host name. My initial suspicion was that maybe it was something related to hostname lookups?

A quick viewing of /etc/hosts showed that there were only entries for localhost and variations - there were none for the real host name. The VM was configured to acquire a dynamic IP via DHCP, but I decided to me a naughtly boy and quickly hack the IP and hostname into /etc/hosts to test the theory. Lo and behold, emacs suddenly popped into life almost immediately!

I can't believe that the VMWare DNS server is so slow as to be the cause of this problem, but now that I have the desired end-result, I'm not wasting any more time on it. I tidied up my mess, by reconfiguring the OS in the VM to have a static address rather than a dynamic one, and all is now fine.

In retrospect, this static/dynamic difference probably explains why I'd experienced the problem intermittently over time - most of my VMs are just for testing, and don't have much configuration from the default, whereas any VM that I use for "real work" will almost certainly have been given a static IP so that I can more easily access it from the host OS.

Amongst my ever growing, never diminishing, pile of hardware are a couple of 1-2 year old Dell netbooks - an Atom based 10" with Win XP Home, and a Celeron 11" with Windows 7. I never had any special plans for either of these machines, they were mainly bought because they were amazingly cheap - the 10" was £209 in Autumn 2009, the 11" £229 in Summer 2010, both of which were around £50-100 less than the going rate for comparable hardware at the time.

Since getting the 11" machine, the 10" has had pretty minimal use. Even with a supposedly "low-end" OS like XP Home, the crummy CPU coupled with 1GB of RAM means it's a pretty chuggy experience - probably not helped by the mountains of pre-installed crap that Dell shoved on it. (The Win 7 machine was much, much cleaner in this regard.)

Now, I do have an Atom based desktop machine running Fedora 11, and that's perfectly usable for the most part - albeit with a slightly better spec Atom processor, but with the same 1GB of RAM. As such, it seemed to make sense to look at getting Linux on the unused netbook, which might give it a bit more regular workout. Both of the netbooks have had a few distros installed within VMWare, but unsurprisingly they don't run that great, performance-wise, but I'm hopeful that Linux running natively should be a decent experience.

The last time I installed Linux natively on a laptop was around 2004/5, and whilst I was happy with how it run, I never got the wifi working. In all honesty, I don't think I actually spent much - if any - effort trying to fix it; I was quite content to use a wired connection. However, the experience made me wary of expecting too much by way of Linux compatibility on laptop hardware; hence why I've generally stuck to running distros within VMs, and letting the underlying pre-installed OS worry about the hardware.

Also, I'm loathe to ever get rid of the originally installed OS on any machines I buy, so I run them as dual-boot. I don't think I'd ever had much of an issue on this before now, but that was before I encountered the mysterious of Dell's restore functionality...

All this blather is leading up to a series of posts I'm planning, that document the trials and tribulations of doing what in theory should be a fairly straightforward task - getting a modern, well-establish and widely used Linux distro (Fedora 14) running on what would seem to be fairly mundane, well understood and supported mass-market hardware (Dell netbook). Unfortunately, this isn't the case :-( Most or all of the areas I'll cover in this series is documented on the net, but it's all rather disjointed, so hopefully I can collate it all here for any other lost souls who set on this path.

To be continued...