host(1) & nslookup(1) hang, but name resolution ... works??!?

David Wolfskill david at
Wed Nov 28 07:17:04 PST 2007

OK; this is weird and probably rather vaguer than anyone would like.

I noticed this yesterday, but I needed to actually use my laptop at
work, so I didn't really have much opportunity to poke around.  I did
some poking around this morning (on booting yesterday's CURRENT to build
today's), and here's some background and what I found:

* I normally run the laptop as a DHCP client.

* In dhclient-exit-hooks, I have a bit of code that uses the just-
  acquired IP address as an argument to host(1), then parses the output
  to determine a hostname to assign to the laptop.  This has been
  working for a very long time -- definitely as far back as FreeBSD 4.8;
  probably earlier than that.  It still works fine in RELENG_6 &
  RELENG_7 (which I also track daily; the laptop gets a fair workout).

* I'm presently running:

FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #604: Tue Nov 27 07:17:37 PST 2007     root at  i386

  which is where I first noticed the issue:  the invocation of host(1)
  appears to hang.

* I tried invoking host(1) from the command line; that invocation also hung.

* nslookup(1) also hung.

* I tried running tcpdump(1), then invoking host(1); there was no
  indication of network traffic at all.

* I tried running host(1) under ktrace(1); running kdump(1) with "-E"
  flag so I can see some timing, the output ends with:

  9739 initial thread 0.010794 CALL  getsockname(0x3,0xbfbfe140,0xbfbfe15c)
  9739 initial thread 0.010820 RET   getsockname 0
  9739 initial thread 0.010837 CALL  close(0x3)
  9739 initial thread 0.010874 RET   close 0
  9739 initial thread 0.010892 CALL  socket(PF_LOCAL,SOCK_STREAM,0)
  9739 initial thread 0.010934 RET   socket 3
  9739 initial thread 0.010951 CALL  close(0x3)
  9739 initial thread 0.010982 RET   close 0
  9739 initial thread 0.012502 CALL  _umtx_op(0xbfbfe0ac,0x3,0x1,0,0)
  9739 initial thread 0.012535 RET   _umtx_op 0
  9739 initial thread 0.012552 CALL  sigprocmask(SIG_BLOCK,0xbfbfe040,0x28501190)
  9739 initial thread 0.012569 RET   sigprocmask 0
  9739 initial thread 0.012597 CALL  _umtx_op(0x283168a0,0x5,0,0,0)
  9739 initial thread 19.115591 RET   _umtx_op RESTART
  9739 initial thread 19.115650 PSIG  SIGKILL SIG_DFL

  As you can see, I waited about 19 seconds before killing the host(1)
  process (with SIGKILL).

* Despite all of this, hostname resolution is actually working -- e.g.,
  I can ping using a hostname:

g1-1(8.0-C)[21] ping -c 2
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=56 time=14.120 ms
64 bytes from icmp_seq=1 ttl=55 time=14.583 ms

--- ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.120/14.351/14.583/0.231 ms

  which is a fairly useful thing, since I'm actually sending this
  message from my internal mailhost (vs. my laptop).  (It's also
  something of which I wasn't aware yesterday at work, or I might
  have been able to report this earlier.)

*  Here's what ps(1) has to say:
g1-1(8.0-C)[23] ps xwwl
 1001 24683 24682   0  20  0  4500  2588 pause  Is    pe    0:00.06 csh
 1001 24920 24683   0  44  0  5596  1896 umtxn  I+    pe    0:00.01 host

* The host(1) process is not killed by SIGTERM, but SIGKILL does the job.

As noted, I'm building today's CURRENT now; if there's a change in
the behavior, I'll send a follow-up note.

I keep a local CVS repo mirror handy, and am not at all averse to
testing patches.

If there are other aspects of the behavior I might check on, please
let me know.

David H. Wolfskill				david at
Proprietary data formats obfuscate, rather than disseminate, information.

See for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url :

More information about the freebsd-current mailing list