British Telecom and Emacs

As I moved to Airbnb host in London and opened my laptop for getting some work done tonight – much to my chargin Emacs won’t start and just hang during startup.

One of the problems of constantly tweaking your editor configuration is – you blame yourself if things go south and I did promptly. Tried to revert to an earlier version of Emacs configuration, tried to undo some of recent shell config changes but no avail.

Very quickly though, I figured out – Emacs is hanging while loading tramp.el. Now that was weird – I wasn’t actually using tramp; it was just being loaded by rubocop.el which I use
when writing Ruby. Removing rubocop.el made Emacs go further but it still got hung bit later.

I enabled debug-on-quit thingy in Emacs and tried to manually load my ruby-mode settings (which included loading rubocop.el) and pressed Control-G when it got hung and I got some error from:

 (setq result "-o ControlMaster=auto")))
   (unless (zerop (length result))
         (with-temp-buffer
           (call-process
            "ssh" nil t nil "-o" "ControlPath=%C" "host.does.not.exist")

Further research pointed me to bit of tramp code that defines a custom variable to select ssh-control options. The variable has
a default value which gets determined by trying to SSH to an non-existant host called host.does.not.exist. I know what you are thinking, stupid – right?

Thankfully they are trying to fix it – http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00137.html

So, where does BT come in all of this? If you fire your terminal and try to ping host.does.not.exist you will probably get:

hyperion? ~> ping host.does.not.exist
ping: unknown host host.does.not.exist

Not on the connection I was though. BT in its infinite wisdom has configured routes to unknown hosts to hop all over the place and as a result any attempt to ping or ssh to unknown hosts will result in ping/ssh command to wait for real long time.

This obviously made any attempts to require/load tramp.el while I am connected to BT network hang forever (or real long time). There are couple of workarounds – reduce SSH timeout or make host.does.not.exist point to 127.0.0.1 etc.

Leave a Reply

Your email address will not be published. Required fields are marked *