slow startup for xemacs on Darwin

Fri Jul 23 20:09:22 EDT 2010

I actually found out what xemacs is doing.  It is calling
getaddrinfo("/tmp/launch-gcmVOm/org.macosforge.xquartz", ...); 
That comes from the DISPLAY name.  Why is it doing this, and can I tell it not to?  On Mac OS X, this is the weird name that DISPLAY gets set to to get direct rendering. It does not work to set DISPLAY to ":0".  I don't want to use DISPLAY="rcmac.llnl.gov:0" because that will cause it to hit the NIC instead of go straight to the card for rendering. 

On Jul 23, 2010, at 5:03 PM, Hamish Macdonald wrote:

> On Fri, Jul 23, 2010 at 7:13 PM, Richard Cook <rcook at llnl.gov> wrote:
> Can you give me a command line for that?  I'm not sure how to capture what xemacs is doing with getaddrinfo using tcpdump.  Thanks!  
> 
> 
> You could do two captures, one of just port 53 (DNS) traffic, and a second where you capture everything.
> If you are on Wifi, you should use "-i en1".  If you are on ethernet, you should use "-i en0".
> 
> So for DNS traffic only, when connect to Wifi:
> 
> $ sudo tcpdump -i en1 port 53 2>&1 | tee capture.out
> 
> For all traffic when on Ethernet:
> 
> $ sudo tcpdump -i en0 2>&1 | tee capture.out
> 
> While one of these captures is running, start xemacs.
> 
> Type Ctrl-C in the window where the tcpdump is running when you want to stop capturing.  The "capture.out" file will contain the results.
> 
> Regards, 
>   Hamish.
> 
> On Jul 23, 2010, at 12:36 PM, Hamish Macdonald wrote:
> 
>> Collect a tcpdump while it's failing
>> 
>> On Fri, Jul 23, 2010 at 2:37 PM, Richard Cook <rcook at llnl.gov> wrote:
>> Hi, thanks for helping with this.  I have a few more questions below.
>> 
>> On Jul 22, 2010, at 11:31 PM, Stephen J. Turnbull wrote:
>> 
>> > Richard Cook writes:
>> >
>> >>> special issues there), I've had a couple of reports that other people
>> >>> who have been cajoled into getting a proper DNS service (or in one
>> >>> case where there really wasn't supposed to be a DNS service, blocking
>> >>> port 53 which gives an immediate failure rather than timing out) have
>> >>> other programs suddenly start working better.
>> >>
>> >> What exactly is it that you think is wrong with the network?  I
>> >> would love to fix this, but I'm not sure exactly what's wrong.
>> >
>> > In an IPv6-ready network, every host must have a canonical name in the
>> > DNS, and it must get that from the network.  I see from the build ID
>> > that your host thinks it's "rcmac.llnl.gov".  However, it can come
>> > from other sources than the network, and I guess it does (/etc/hosts,
>> > or the Mac's own directory services).  Hanging for "several minutes"
>> > presumably means that your computer is connected to a network (perhaps
>> > a wireless network that you haven't logged into yet), and the attempt
>> > to get a canonical name fails.
>> 
>> Just as a data point, so you are clear, "several minutes" is not an exaggeration.  It's not a 30 second thing, not a 60 second thing, it's multiple minutes.  If I wait long enough, a window will appear eventually.  I haven't timed it yet, though.
>> 
>> >
>> > If there was no network, this should fail instantaneously.  I can only
>> > guess that there is no DNS on your internal network, or that it is
>> > behind a firewall.  If those are based on policy, you will need an
>> > XEmacs that is properly configured for that environment (ie,
>> > --without-ipv6-cname).
>> 
>> There certainly is DNS on our internal network, and it certainly behind a firewall.
>> 
>> >
>> > I suppose it's not possible that this workstation at one time had a
>> > dialup connection, it thinks it's still active, and you're starting
>> > XEmacs in a no-network configuration?
>> 
>> Nope, this is a brand new macintosh.  It is configured to use DHCP on a fairly ordinary ethernet network with many computers on it.  DHCP always gives it the same address.  The only thing unusual is the number of firewalls.
>> 
>> >
>> >>>> However, when I try to configure with that option, the configure
>> >>>> script ignores it.  I can see that it theoretically takes it.
>> >>>
>> >>> Are you sure the configure script ignores it?
>> >>
>> >> Well, I was just going with the errors that configure reported as I
>> >> described earlier, which told me that those options were errors and
>> >> ignored.
>> >
>> > Hm.  You didn't say that the configure script was complaining, just
>> > that the argument was ignored.  With the upstream sources,
>> > "./configure --without-ipv6-cname" works as expected on both my Linux
>> > and Mac OS X 10.5 systems.  No complaints about ignored arguments.
>> 
>> Sorry, here is the output.  I'm building xemacs-21.5.29, by the way, maybe we are using different versions?  When I give --without-ipv6-cname, I get the following from the configure script:
>> 
>> configure:42727: WARNING: unrecognized options: --without-ipv6-cname
>> 
>> Here's the whole log, which will probably cause my email to bounce.  :-)
>> 
>> 
>> 
>> >
>> > Are you using xemacs.org sources, or sources from MacPorts?
>> 
>> I've tried both.
>> 
>> > Have you run autoconf yourself?
>> 
>> Yes.
>> 
>> >
>> >>> Ie, even though you
>> >>> specify --without-ipv6-cname, src/config.h contains
>> >>>
>> >>> #define IPV6_CANONICALIZE 1
>> >
>> > As a quick hack, you could try
>> >
>> > port uninstall xemacs
>> > port configure xemacs
>> > pushd `port work xemacs`
>> > # edit xemacs-21.4.22/src/config.h
>> > # change above line to "/* #undef IPV6_CANONICALIZE */"
>> > popd
>> > port install xemacs
>> >
>> 
>> I tried #undef IPV6_CANONICALIZE and it did not resolve the hanging issue.
>> and I also tried #define IPV6_CANONICALIZE 1 and it also still hangs.  So probably the whole IPV6 canonical thing is a red herring.  There is some other reason that getaddrinfo is hanging.
>> 
>> I did confirm that I'm actually using what I'm building too.  :-)
>> 
>> --
>> ✐Richard Cook
>> ✇ Lawrence Livermore National Laboratory
>> Bldg-453 Rm-4024, Mail Stop L-557
>> 7000 East Avenue,  Livermore, CA, 94550, USA
>> ☎ (office) (925) 423-9605
>> ☎ (fax) (925) 423-6961
>> ---
>> Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
>> (opinions expressed herein are mine and not those of LLNL)
>> 
>> 
>> 
>> 
>> _______________________________________________
>> XEmacs-Beta mailing list
>> XEmacs-Beta at calypso.tux.org
>> http://**calypso.tux.org/mailman/listinfo/xemacs-beta
>> 
>> 
> 
> -- 
> ✐Richard Cook   
> ✇ Lawrence Livermore National Laboratory
> Bldg-453 Rm-4024, Mail Stop L-557        
> 7000 East Avenue,  Livermore, CA, 94550, USA
> ☎ (office) (925) 423-9605    
> ☎ (fax) (925) 423-6961
> ---
> Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
> (opinions expressed herein are mine and not those of LLNL)
> 
> 
> 
> 

-- 
✐Richard Cook   
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557        
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605    
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)