Previous INDEX Next
Migrating to a mirror raid on Debian Migrating from Thunderbird to Outlook email

Emacs startup delay on Windows 7

NOTE: The solution outlined in this journal entry is very specific to running emacs on a laptop which is part of a Windows domain, and where the laptop is often used disconnected from the domain. If this doesn't describe your setup, you might as well stop reading now.

Emacs (23.2) on my Windows 7 work laptop was annoying slow when starting (around 10s). If closed and restarted, startup was immediate until, after about 30 seconds, it was slow again. According to Google, slowness might be due to failing DNS lookups of the laptop's hostname. This could have been the case; in my local DNS, the laptop has a domain of hydrus.org.uk, but due to corporate lockdown, the laptop thought it belonged the corporate domain. Adding the laptop's host name to Windows hosts file, the most common solution on the web, didn't make any difference to emacs startup.

To see what emacs startup was generating, I turned on query logging on my local DNS, by adding an entry like this in the named.conf file: 

  logging {
      channel query_logging {
           file "/var/log/named_querylog"
           versions 3 size 100M;
           print-time yes;                 // timestamp log entries
        };

        category queries {
            query_logging;
        };
  };

Control of the logging is managed by rndc; toggle logging on and off by rndc querylog. You can examine the current status through rndc status.

So, what was hitting the DNS when emacs started up? I was surprised to find something like this: 

  19-Mar-2012 19:50:16.157 client 192.168.0.60#64524: query: _ldap._tcp.ZZZ._sites.dc._msdcs.YYY.XXX.com IN SRV +
  19-Mar-2012 19:50:16.213 client 192.168.0.60#52064: query: _ldap._tcp.dc._msdcs.YYY.XXX.com IN SRV +
  19-Mar-2012 19:50:16.244 client 192.168.0.60#55630: query: _ldap._tcp.c3a747ef-3e40-4067-b64e-5d4dc0bdc331.domains._msdcs.XXX.com IN SRV +

These turn out to be Windows Domain Controller lookups from the Windows Netlogon service. So, I turned off the Netlogon service and sure enough, no more queries and emacs started up instantly.

I wasn't sure what effect turning off Netlogon would have when I was in the office and connected to the corporate network. I therefore tried another approach, seeing if the fact that emacs started quickly immediately after a first slow startup could be leveraged. More digging on Google. I found this article, which enabled me to increase the negative cache timeout: 

  The negative cache period
  
  Description: The NegativeCachePeriod entry specifies the time that a
  client will remember that a domain controller could not be found in
  a domain. If a program tries again within this time, the client call
  immediately fails without trying to find a domain controller again.

  Subkey:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  Entry: NegativeCachePeriod
  Type: DWORD
  Default value (seconds): 45
  Recommended value: 84600

I set it to 43200 (12 hours). It appeared to work. Excellent, job done.

Except later, the NegativeCachePolicy time was ignored, seemingly correlated with the time I started up the VPN to access the corporate network. Emacs startup was once again causing DC lookups. So, I also found reference to a similar setting in Policies: HKLM\Software\Policies\Microsoft\Netlogon\Parameters!NegativeCachePeriod. Setting this seemed to make netlogon behave again, but as soon as I started the VPN, emacs when back to invoking DC lookups. Presumably the monkeying around the VPN does with the communication stack somehow resets the cache.

So, stopping Netlogon seemed to be the most consistent approach. I put the necessary commands to stop and start Netlogon into batch files and made shortcuts to them available on the TaskBar, via a ToolBar (I have a folder called TaskLets for this purpose). The commands are simple:

StartNetLogon.bat is: 

  net start netlogon

and StopNetLogon.bat is: 

  net stop netlogon

I spend most of my time out of the office, so running without Netlogon is not an issue. However, the next time I used my laptop in the office and on the corporate network, I didn't find the absence of Netlogon any problem at all. My use of corporate resources at the Windows level is pretty minimal. However, just to be on the safe side, I've left Netlogon to start automatically on boot, just in case somewhere, sometime, I'm bitten.

Previous INDEX Next
Migrating to a mirror raid on Debian Migrating from Thunderbird to Outlook email

GNU/Linux Logo