10:49 p.m.
I have been trying to track down why xemacs beta takes forever to
start when my network is down when XEmacs 21.1 worked just fine.
It turns out that `unix_canonicalize_host_name' has been changed to
call `getaddrinfo' instead of the old call to `gethostbyname' (via
`get_internet_address'). What is the advantage of 'getaddrinfo' over
'gethostbyname'?
For people like me with not-completely-reliable dsl modems, it makes
xemacs beta unusable under X.
An easy way to test this is too change all your nameservers in
/etc/resolv.conf to a bogus ip.
Sean
4:39 a.m.
On Mon, 18 Dec 2000 17:49:36 EST, Sean MacLennan <seanm(a)storm.ca> said:
It turns out that `unix_canonicalize_host_name' has been changed
to
call `getaddrinfo' instead of the old call to `gethostbyname' (via
`get_internet_address'). What is the advantage of 'getaddrinfo' over
'gethostbyname'?
getaddrinfo() supports IPv6 addresses as well.
It *should* behave about the same as gethostbyname() regarding network
accesses that hang/time out - if one is hanging and the other is not,
that's either a config error or software bug.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
1:55 a.m.
Valdis.Kletnieks(a)vt.edu writes:
It *should* behave about the same as gethostbyname() regarding
network
accesses that hang/time out - if one is hanging and the other is not,
that's either a config error or software bug.
I tried the following code:
struct hostent *host_info_ptr;
host_info_ptr = gethostbyname("localhost");
time ./t
7f000001
./t 0.00s user 0.00s system 0% cpu 0.000 total
Then this:
char addrbuf[NI_MAXHOST];
struct addrinfo hints, *res;
int retval;
memset(&hints, 0, sizeof(hints));
hints.ai_flags = AI_CANONNAME;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = 0;
retval = getaddrinfo("localhost", NULL, &hints, &res);
time ./t
127.0.0.1
./t 0.00s user 0.00s system 0% cpu 2:30.08 total
The gethostbyname goes straight to the hosts file and returns the
result. The getaddrinfo call first goes through the nameserver. When
that fails, it *then* tries the host file.
For the record I am running Mandrake 7.1 with the 2.4.0-test12 kernel
and glibc-2.1.3-17mdk.
Sean
5:10 a.m.
>>>> "Valdis" == Valdis Kletnieks
<Valdis.Kletnieks(a)vt.edu> writes:
Valdis> On Mon, 18 Dec 2000 17:49:36 EST, Sean MacLennan
Valdis> <seanm(a)storm.ca> said:
> It turns out that `unix_canonicalize_host_name' has been
> changed to call `getaddrinfo' instead of the old call to
> `gethostbyname' (via `get_internet_address'). What is the
> advantage of 'getaddrinfo' over 'gethostbyname'?
Valdis> getaddrinfo() supports IPv6 addresses as well.
It's also reentrant, and doesn't return info in a static buffer. Not
to mention having a nice flexible set of flags ...
Valdis> It *should* behave about the same as gethostbyname()
Valdis> regarding network accesses that hang/time out - if one is
Valdis> hanging and the other is not, that's either a config error
Valdis> or software bug.
...which in the default configuration under some releases of
Linux/glibc (for one) cause getaddrinfo() to do some dns lookups (on
localhost, to get its CNAME) that gethostbyname() does not, and these
are causing the hang.
See the thread rooted at
http://www.xemacs.org/list-archives/xemacs-beta/200007/msg00348.html
for more info. There seems to be a claim there the hanging behavior
of getaddrinfo() is somehow more PC than that of gethostbyname().
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:11 a.m.
Stephen J. Turnbull writes:
See the thread rooted at
http://www.xemacs.org/list-archives/xemacs-beta/200007/msg00348.html
Thanks! In the message
http://www.xemacs.org/list-archives/xemacs-beta/200007/msg00374.html
Hideaki YOSHIFUJI had the following info:
One solution against the problem that it would take long time to
resolve names is to define a new runtime-configuration variable
which selects protocol family being given to getaddrinfo()
through 'hints':
:
memset(&hints, 0, sizeof(hints));
hints.ai_familt = af; /* <= set this value by configuration variable:
PF_UNSPEC: IPv6->IPv4 (default)
PF_INET : IPv4
PF_INET6 : IPV6
xemacs' default should be PF_UNSPEC, but
it may be configurable by autoconf.
Even in this case, xemacs MUST allow
users to set this value through
runtime-variable by thamselves:
Red Hat can set configuration variable
PF_INET by default, but users MUST be
able to change that to PF_UNSPEC. */
If I change the ai_family from PF_UNSPEC (it is currently AF_UNSPEC)
to PF_INET, the problem goes away.
Now, how do we make sure this dosen't get dropped again?
Sean
6:49 a.m.
>>>> "Sean" == Sean MacLennan
<seanm(a)storm.ca> writes:
Sean> If I change the ai_family from PF_UNSPEC (it is currently
Sean> AF_UNSPEC) to PF_INET, the problem goes away.
Sean> Now, how do we make sure this dosen't get dropped again?
PROBLEMS file, I guess?
There's a "slow startup on Linux" item. Maybe Martin has an opinion
about whether this should be generalized to "Slow Startup / Often
reported on Linux"?
Possibly we also ought to consider implementing a Lisp variable and
maybe a command line option (since the lookup is pretty early) to
implement the solution you're using.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
6:13 a.m.
>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
>>>> "Sean" == Sean MacLennan
<seanm(a)storm.ca> writes:
Sean> If I change the ai_family from PF_UNSPEC (it
is currently
Sean> AF_UNSPEC) to PF_INET, the problem goes away.
Sean> Now, how do we make sure this dosen't get dropped again?
SJT> PROBLEMS file, I guess?
SJT> There's a "slow startup on Linux" item. Maybe Martin has an
opinion
SJT> about whether this should be generalized to "Slow Startup / Often
SJT> reported on Linux"?
Martin has the opinion that he should take a month and really fix the
problem. Martin vaguely recalls there was a problem with getaddrinfo
in Red Hat 6.0 (and presumably other Linuxen) that was fixed in 6.1.
Hideaki had a patch, but its GPL-compatibility was in question and
it needed some more work to properly lispify/autoconfiscate.
Martin thinks that /etc/nsswitch.conf (see nsswitch.conf(5)) should
control whether dns is consulted before /etc/hosts.
SJT> Possibly we also ought to consider implementing a Lisp variable and
SJT> maybe a command line option (since the lookup is pretty early) to
SJT> implement the solution you're using.
Creating yet another lisp variable is relatively easy. It's harder to
know exactly what the Right Thing is.
6:36 a.m.
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> Hideaki had a patch, but its GPL-compatibility was in question
mb> and it needed some more work to properly
mb> lispify/autoconfiscate.
?? The change I mentioned in PROBLEMS was one preprocessor token, and
there is no alternative for the functionality => no copyright issues.
How hard could it be to control that with a Lisp variable?
The only problem I can see is that the odds seem to be that the
offending function is getting called way early in startup, before the
Lisp engine exists.
There is also
From: karlheg(a)bittersweet.member.dsl-only.net (Karl M. Hegbloom)
Message-ID: <8766keurdy.fsf(a)bittersweet.intra>
Subject: Re: ipv6 AAAA record lookup is making programs hang at startup.
Date: 21 Dec 2000 00:10:01 -0800
from xemacs-beta yesterday which seems to suggest that Debian has a
handle on this, and that will surely be GPL-compatible.
mb> Martin thinks that /etc/nsswitch.conf (see nsswitch.conf(5))
mb> should control whether dns is consulted before /etc/hosts.
/etc/hosts doesn't know squat about CNAMEs AFAIK, which is what we're
getting in the part of the code that causes the problem.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
4:49 a.m.
Sean MacLennan <seanm(a)storm.ca> writes:
I have been trying to track down why xemacs beta takes forever to
start when my network is down when XEmacs 21.1 worked just fine.
It turns out that `unix_canonicalize_host_name' has been changed to
call `getaddrinfo' instead of the old call to `gethostbyname' (via
`get_internet_address'). What is the advantage of 'getaddrinfo' over
'gethostbyname'?
getaddrinfo() supports IPV6 names, so it is a 'good thing' in theory.
-bp
4:52 a.m.
Sean MacLennan <seanm(a)storm.ca> writes:
I have been trying to track down why xemacs beta takes forever to
start when my network is down when XEmacs 21.1 worked just fine.
It turns out that `unix_canonicalize_host_name' has been changed to
call `getaddrinfo' instead of the old call to `gethostbyname' (via
`get_internet_address'). What is the advantage of 'getaddrinfo' over
'gethostbyname'?
It is a more modern API and supports protocols that are not IPv4 - IPv6
specifically, but applications that use `getaddrinfo' and company should
be able to support /any/ protocol that supports streams with no code
changes.
In the context of the specific function, it would make XEmacs work
correctly on an IPv6 only node. :)
For people like me with not-completely-reliable dsl modems, it makes
xemacs beta unusable under X.
An easy way to test this is too change all your nameservers in
/etc/resolv.conf to a bogus ip.
This problem does not show up when you use the old sockets API, but does
when you use the new one? Odd.
You could try adding an entry to /etc/hosts with your machine name and
address...
Daniel
--
My definition of an expert in any field is a person who knows enough about
what's really going on to be scared.
-- P.J. Plauger
8519
days inactive
8523
days old
10 comments
6 participants
participants (6)
-
Daniel Pittman -
Martin Buchholz -
Sean MacLennan -
Stephen J. Turnbull -
Valdis Kl=?iso8859-4?Q?=BA?=tnieks -
William M. Perry