Bug 521146

(In reply to comment #0)
> The who utility has a documented flag (--lookup) that enables looking up
> hostnames in DNS corresponding to the IP address of the logged in user. The
> documentation indicates this is off by default, however it appears to be on by
> default.

Why do you think it appears to be on?

Please attach the output of:
$ strings /var/run/utmp

Are you experiencing any significant delays?

If yes, then please attach output of:
$ strace -r who

[root@firedog ~]# strings /var/run/utmp
reboot
2.6.29.6-217.2.16.fc11.i586
runlevel
2.6.29.6-217.2.16.fc11.i586
tty5
LOGIN
tty3
LOGIN
tty6
LOGIN
tty4
LOGIN
tty2
LOGIN
tty1
pts/0
:0.0
pts/1
ts/1root
68-29-93-120.pools.spcsdns.net
pts/2
ts/2ev
srv.foo21.com
pts/3
ts/3root
65.103.33.174
pts/4
ts/4root
65.103.33.174

So... I thought the IP was always logged in utmp and who was interpreting them, I guess its sshd that's resolving the IP and logging it there (and yes I get delays when DNS isn't working right for some reason, but they are during login as one would expect, not running who).

If I turn off the UseDNS option in sshd I do see IP's, though it appears --lookup doesn't resolve the ones that should be resolvable (which was not the topic of this bug, if its appropriate I will open another one if you like):

NEW firedog ~$ who
ev       tty1         2009-08-31 00:22 (:0)
ev       pts/0        2009-08-31 00:32 (:0.0)
root     pts/3        2009-09-03 16:25 (65.103.33.174)
ev       pts/4        2009-09-03 17:40 (192.172.252.16)
NEW firedog ~$ who --lookup
ev       tty1         2009-08-31 00:22 (:0)
ev       pts/0        2009-08-31 00:32 (:0.0)
root     pts/3        2009-09-03 16:25 (65.103.33.174)
ev       pts/4        2009-09-03 17:40 (192.172.252.16)
NEW firedog ~$ host 192.172.252.16
16.252.172.192.in-addr.arpa domain name pointer srv.foo21.com.


Apologies, I will close this as invalid and find an alternate way to get a list of raw IP's from which people are logged in on.

Thanks for your time!

Thanks for the analysis! As for the unresolved IPs, this seems like the relevant code, doing the canonicalization:

  static struct addrinfo hints;
  struct addrinfo *res = NULL;
  int status;

  hints.ai_flags = AI_CANONNAME;
  status = getaddrinfo (host, NULL, &hints, &res);

I'll check if it is bug or documented behavior. You don't need to open a separate ticket for now.

This also does not look like a coreutils bug. The 'who' utility attempts to canonicalize hostname as documented. However result is the same as input:

canon_host_r (host=0x7fffffffdb40 "10.34.33.205", cherror=0x60e500) at canon-host.c:69
69        hints.ai_flags = AI_CANONNAME;
(gdb) f
#0  canon_host_r (host=0x7fffffffdb40 "10.34.33.205", cherror=0x60e500) at canon-host.c:69
69        hints.ai_flags = AI_CANONNAME;
(gdb) n
70        status = getaddrinfo (host, NULL, &hints, &res);
(gdb)
71        if (!status)
(gdb) inf lo
retval = 0x0
hints = {
  ai_flags = 2,
  ai_family = 0,
  ai_socktype = 0,
  ai_protocol = 0,
  ai_addrlen = 0,
  ai_addr = 0x0,
  ai_canonname = 0x0,
  ai_next = 0x0
}
res = 0x6133f0
status = 0
(gdb) print *res
$2 = {
  ai_flags = 2,
  ai_family = 2,
  ai_socktype = 1,
  ai_protocol = 6,
  ai_addrlen = 16,
  ai_addr = 0x613420,
  ai_canonname = 0x6132e0 "10.34.33.205",
  ai_next = 0x613440
}