[root@GFVM4 ~]# hostname
[root@GFVM4 ~]# 
[root@GFVM4 ~]# 
[root@GFVM4 ~]# getent hosts gfvm4 GFVM4
[root@GFVM4 ~]# getent hosts GFVM4
fe80::5054:ff:feac:787 GFVM4
[root@GFVM4 ~]# 
[root@GFVM4 ~]# 
[root@GFVM4 ~]# 
[root@GFVM4 ~]# ifconfig ens5
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::5054:ff:feac:787  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:ac:07:87  txqueuelen 1000  (Ethernet)
        RX packets 452  bytes 33008 (32.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 204  bytes 26112 (25.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@GFVM4 ~]# 

Is the above expected behaviour?

As you can see I have setup all caps HOSTNAME GFVM4.

if I use the same name(ALL CAPS) it returns ipv6 address. If I use small lettered hostname, it returns ipv4 address.

Is this correct behaviour?

Running Fedora21 as a qemu based VM.


  • 2
    Can you post the contents of /etc/hosts ? – Per von Zweigbergk Sep 28 '15 at 19:44
  • Is it always reproducible, or does it return either one address or the other, regardless of the case? – cnst Sep 28 '15 at 22:55

This will not be a complete answer, just want to share my findings, and it's too long to fit in comments...

First, if you want to reply on getent you need to have the right config in /etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts, etc. I have a Fedora 22 and it has the following line in /etc/nsswitch.conf.

hosts:    files mdns4_minimal [NUTFOUND=return] dns myhostname

getent hosts localhost and getent hosts LOCALHOST give different results. But after I changed /etc/nsswitch.conf to have hosts: files, they give the same result.

I think when you have multiple sources to search, they may treat case differently and give inconsistent results.

Second, you may want to try getent ahost. It uses getaddrinfo() instead of gethostbyname2(). It gives more consistent answers at least in my case. See man getent.

Third, I found it interesting to read the source code getent.c and watch the trace by ltrace getent hosts localhost. There you can see inet_pton() and gethostbyname2(). You can also trace system calls by ltrace -S and you can see what files are opened, such as /etc/hosts.

Below is the output of ltrace. AF_INET6 (10) is tried before AF_INET (2).

[a@localhost ~]$ ltrace getent hosts LOCALHOST
__libc_start_main([ "getent", "hosts", "LOCALHOST" ] <unfinished ...>
mtrace()                                                                                                     = <void>
setlocale(LC_ALL, "")                                                                                        = "en_US.UTF-8"
textdomain("libc")                                                                                           = "libc"
argp_parse(0x606440, 3, 0x7ffc1cf8a7c8, 0)                                                                   = 0
strcmp("hosts", "hosts")                                                                                     = 0
inet_pton(10, 0x7ffc1cf8c67a, 0x7ffc1cf8a680, 0)                                                             = 0
inet_pton(2, 0x7ffc1cf8c67a, 0x7ffc1cf8a680, 0x658e2f20)                                                     = 0
gethostbyname2(0x7ffc1cf8c67a, 10, 0x7ffc1cf8a680, 0x658e2f20)                                               = 0
gethostbyname2(0x7ffc1cf8c67a, 2, -20, 0x7f166586c8f5)                                                       = 0x7f1665b16260
inet_ntop(2, 0xc47000, 0x7ffc1cf8a620, 46)                                                                   = 0x7ffc1cf8a620
printf("%-15s %s", "", "localhost.localdomain")                                                     = 37
__overflow(0x7f1665b13620, 32, 0, 0x7fffffda)                                                                = 32
fputs_unlocked(0xc47041, 0x7f1665b13620, 0x7f1665d36025, 0xfbad2a84)                                         = 1
__overflow(0x7f1665b13620, 10, 0xc47050, 0x74736f686c61636f127.0.0.1       localhost.localdomain localhost
)                                                 = 10
+++ exited (status 0) +++

Finally, my suggestion is either 1) control the source of getent in /etc/nsswitch.conf; or 2) maintain your own database/dictionary.


Just a guess but, from http://linuxmanpages.net/manpages/fedora21/man1/getent.1.html:

hosts     When no key is provided, use sethostent(3), gethostent(3),
                    and  endhostent(3)  to enumerate the hosts database.  When
                    one or more key arguments are provided, pass each  key  to
                    gethostbyaddr(3)   or   gethostbyname2(3),   depending  on
                    whether a call to inet_pton(3) indicates that the  key  is
                    an IPv6 or IPv4 address or not, and display the result.

In http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/usr.bin/getent/getent.c "if (argc == 2)" means "% getent hosts" (no key provided), so this is performed:

    for (i = 2; i < argc; i++) {
        if (inet_pton(AF_INET6, argv[i], (void *)addr) > 0)
            he = gethostbyaddr(addr, IN6ADDRSZ, AF_INET6);
        else if (inet_pton(AF_INET, argv[i], (void *)addr) > 0)
            he = gethostbyaddr(addr, INADDRSZ, AF_INET);
            he = gethostbyname(argv[i]);
        if (he != NULL)
        else {
            rv = RV_NOTFOUND;

I'm not great in C, and the only source I found by a quick googling refers to NetBSD, but it seems that if the first inet_pton (http://linuxmanpages.net/manpages/fedora21/man3/inet_pton.3.html) find an entry for IPv6, the second function for IPv4 is skipped. Also, I didn't see any forcing of the case at first look (meaning that case-insentive seems not forced).

That said, you may have 2 entries for GFVM4, one is upper and the other is lower. The upper one has probably an IPv6 address associated.

It would be great if you could provide confirm or not about different entries in different case, in order to confirm (or not). If confirmed, I'd say it's the expected behaviour of the getent software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.