gg> Okay it happened again. Attempting to reply to an email through VM
gg> & got the unknown host error. This time I had some things ready.
gg> and sure enough this paused Emacs for a while and then spit out
gg> the "unknown host" message in the minibuffer. On restarting Emacs
gg> and running this again, it made the connection just fine and the
gg> SMTP greetings line showed up in my scratch buffer.
I have seen similar problems (on my laptop running RedHat Linux). I
don't have a good solution, but the workaround you came across
(restarting emacs) is what I do. Here is my wild speculation about
what is going on.
Like most UNIX applications, the first time you need to resolve a
domain name emacs calls the resolver library. The resolver library
reads /etc/resolv.conf to get the IP addresses of the DNS servers you
use. It then remembers those IP addresses for next time (ie, it
doesn't re-read /etc/resolv.conf).
When you connect to your ISP, your PPP daemon is probably creating a
new /etc/resolv.conf with the "right" DNS servers. Ditto for using
DHCP to get an IP address on the local LAN. Although your ISP DNS
servers may or may not be visible in the Internet at large, it is
reasonably likely that your LAN DNS servers are behind some firewall
and not visible outside. So, the steps to calamity (for me, and
perhaps for you) are:
1. Get IP address and DNS server info via DHCP on LAN.
2. Run emacs and read resolv.conf.
3. Wander away, and connect to ISP via PPP.
4. Anything DNS-ish makes emacs hang for a good while.
You are less likely to notice this with other applications since they
don't have the long life of emacs. That's why ping and telnet worked
for you. They were freshly started processes and each read the
current /etc/resolv.conf. Here are some possible and partial
solutions:
1. Just live with it. Restart emacs as necessary to pick up new DNS
info, or run two copies of emacs (one for LAN, one for ISP). Ick.
2. Run a local DNS server. Configure your DHCP and PPP to not
overwrite /etc/resolv.conf (which now points at your local machine).
3. It sounds like the resolver is ignoring whatever you put in
/etc/hosts. You may be able to alter it's behavior by messing with
/etc/host.conf (on Linux, various other places on other UNIX
variants). That will be OK for a small number of hosts, but there is
a reason people use DNS instead of /etc/hosts, so don't overdo it.
4. Fill /etc/resolv.conf with DNS servers that are visible in both
cases (ISP and LAN). Configure your DHCP and PPP to not overwrite
/etc/resolv.conf. (You may have trouble finding DNS servers that fit
this constraint, depending on firewalls and various things you can't
control, but it's a good solution if you can find them.)
5. Petition someone who is willing and able to do something about
this in emacs source code. Granted, other apps don't have DNS hacks
in them, but they don't run for months at a time either. I believe
there are C calls that can be made to re-initialize the resolver to
have it re-read /etc/resolv.conf. emacs would just have to keep track
of the timestamp on /etc/resolv.conf and Do The Right Thing. Given
all the stat() and fstat() calls that emacs is doing, it shouldn't be
much of a performance burden to check before most/all resolver calls.
(It would be even cooler if there were a resolver option to do this
internally on behalf of an application, but I don't think there is.)
--
bill(a)carpenter.ORG (WJCarpenter) PGP
bill(a)bubblegum.net 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3