After updating OS X on my work iMac, I noticed XEmacs and DDD take about 30 seconds to launch, behavior I did not see before the upgrade, and do not see at home either. The 30 seconds are suspiciously similar to a name lookup timeout—I am dependent on whatever lame excuse for a DNS caching server is used in my landlord’s 2WIRE router, whereas I run unbound at home.

Sure enough, running a packet trace shows strange DNS lookups:

tellann:src root# tcpdump udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:18:51.819226 IP tellann.58811 > home.domain: 5470+ A? tellann.gateway.2wire.net. (43)
13:18:51.840258 IP home.domain > tellann.58811: 5470* 1/1/1 A 192.168.1.81 (150)
13:18:51.841196 IP tellann.58057 > home.domain: 18746+ A? /tmp/launch-4UITkL/org.x.gateway.2wire.net. (60)
13:18:51.870233 IP home.domain > tellann.58057: 18746 Refused*- 0/0/0 (512)
13:18:52.842654 IP tellann.58057 > home.domain: 18746+ A? /tmp/launch-4UITkL/org.x.gateway.2wire.net. (60)
13:18:52.865696 IP home.domain > tellann.58057: 18746 Refused*- 0/0/0 (512)

The code>DISPLAY environment variable has changed to:

tellann ~>echo $DISPLAY
/tmp/launch-4UITkL/org.x:0

Before 10.6.3, it did not have the org.x bit. This whole approach of using a DISPLAY set to point to a UNIX domain socket was set up by Apple to allow launching X11.app on demand when a X client is run, but obviously many clients make the incorrect assumption that the part before the :0 display number is a hostname if it has a dot in it, and this is biting us.

The solution is simple: just set DISPLAY to :0 prior to launching XEmacs or DDD, and presto—no more delays, e.g:

env DISPLAY=:0 xemacs&