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. There is no obvious way to turn it off if you want the documented behavior. Version-Release number of selected component (if applicable): coreutils-7.2-3.fc11.i586 How reproducible: consistently Steps to Reproduce: 1. Log into a machine with ssh 2. type 'who' or 'who -m' 3. type 'who --lookup' or 'who -m --lookup' Actual results: [root@firedog shorewall]# who ev tty1 2009-08-31 00:22 (:0) ev pts/0 2009-08-31 00:32 (:0.0) root pts/1 2009-09-03 15:14 (68-29-93-120.pools.spcsdns.net) ev pts/2 2009-09-03 15:41 (srv.foo21.com) [root@firedog shorewall]# who --lookup ev tty1 2009-08-31 00:22 (:0) ev pts/0 2009-08-31 00:32 (:0.0) root pts/1 2009-09-03 15:14 (68-29-93-120.pools.spcsdns.net) ev pts/2 2009-09-03 15:41 (srv.foo21.com) Expected results: Similar to above but with raw IP addresses rather than the reverse DNS name in the first invocation. Additional info:
(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 }