I was trying to get a perl script that contacts a PostgreSQL database to work on a server. This script was mysteriously failing. I then realised that localhost was not in the /etc/hosts file.

The file for this machine (currently running Debian lenny) currently looks like       machinename.domain   machinename
xxx.xx.x.xxx    machinename.domain   machinename

The xxx.xx.x.xxx is the IP address. The file for my current home machine, which is a slightly older installation (currently running Debian squeeze) is       machinename          localhost       machinename.domain   machinename

My home machine sits behind a router and is not directly exposed to the internet. In any case, I'm on DSL and have no static IP address.

I've kept /etc under version control for my machines (using etckeeper) for some time, and I see that for this server, the following change was made by some mastermind (possibly myself) on Dec 17th 2009.

-      localhost
+      machinename.domain  machinename

I've wondered before why this file is set up the way this is, but the answer is not obvious. Some questions:

  1. Why This might be a Debian-specific bit of history. I did a bit of searching on the net, and found some vague mutterings about Gnome, but little of any substance.

  2. Where in Debian is the template this file is set from?

  3. Is there currently considered to be a correct/best form for this file?

  4. Is the order of the names in the line significant? I hope not.

More generally, what is the explanation of why these two lines are structured the way they are?

For now, I think I'll change the server /etc/hosts to       machinename.domain  machinename localhost
xxx.xx.x.xxx    machinename.domain  machinename


3 Answers 3



You should have always have    localhost.localdomain localhost

In your case, because you don't have a permanent IP address, you can also have    machinename.domain machinename

This line seems to be required for some applications like GNOME, but it might actually cause problems with other applications!

See Proposed new scheme for resolving the system hostname.

Effectively your machine has two host names.

localhost.localdomain is the name used for private communications between two TCP/IP-capable processes running on the same machine.

machinename.domain is the name used for communications between your machine and machines connected to your machine.

You always want localhost.localdomain to point to (and ::1 if you are using IPv6). That way, all communication between two TCP/IP processes on the same machine will use the lo (loopback) interface, which is usually allowed by firewalls such as iptables, and nothing has to worry about whether your network is available or whether DNS is working.

Some applications such as GNOME 1 try to use your machine's public name for everything, even when talking to the same machine. This is so that one part of GNOME can talk to another part of GNOME, even if it's running on a different machine on your network. (The N in GNOME originally stood for "network".)

Ideally, your machine's name is known using DNS or some other shared database that other machines can also use to determine your machine's address, so that applications on other machines can talk to your machine.

But if your machine's name isn't in DNS, or DNS isn't working, programs like GNOME still need a way to talk to itself.

There have been various ways of modifying /etc/hosts to make this work.

The most common used to be    localhost.localdomain localhost
w.x.y.z      machinename.domain machinename

where w.x.y.z is the address of your primary network interface, e.g. eth0.

That worked OK if your system used a static IP address and was always connected2.

If your system had a dynamic IP address, various scripts were used to edit /etc/hosts to include an entry based on what the DHCP server returned.

But if your system didn't have a permanent network connection, you couldn't add an entry like that because you didn't have a single reliable address.

So then people started doing something like    localhost.localdomain localhost machinename.domain machinename

or    machinename.domain machinename localhost.localdomain localhost

That way, processes that use TCP/IP could still talk to other processes on the same machine, even if they looked up the IP address using the machine's name.

But it broke other applications.

For example, dnsdomainname.

I also remember there being problems where only people on the same machine could connect to a server because the server was only listening3 for connections on the loopback device.

The program would get the machine's name, then look up the address of name, and use the first address found, and bind to that network interface. If your machine's name resolved to address, that meant the service you thought was running on machinename.domain (and was thus available to the whole network), was really only available to other processes running on the same machine.

As Andy points out, the order of the names shouldn't matter. Something trying to look up the host name for would get the first name as the canonical/official/primary name of the host, but because it would resolve forwards and backwards, I can't think how this would cause any problem, unless there is some automated tool for editing /etc/hosts that expects one format or the other.

But I think you should always have a fully-qualified domain name (i.e. a name that includes a domain name) first as I mentioned in format of /etc/hosts.

There is another similar format that uses two lines instead of one, e.g.    localhost.localdomain localhost    machinename.domain machinename

This is a neat trick, because lo's address is really, meaning any address in the 127 network is the loopback device.

I assume this format was used so that tools that need to change the entry for your machinename.domain can do so without touching the localhost... entry.

But note that it still causes machinename.domain to map to lo, so it can still cause the problems I mentioned.

I also just booted up Fedora 15 in a VM and logged into the Gnome desktop, and I couldn't see any TCP/IP connections. They all seem to be using UNIX sockets. So perhaps the entry is no longer needed.


  1. This used to be the case. On my Fedora 15 test machine, it seems to be using UNIX sockets rather than TCP/IP.
  2. Except during system boot before the network has been started.
  3. Really "bound" rather than "listening".
  4. Or any 127.x.x.x address.
  • Thanks for the comprehensive answer. Some comments. 1. You write "localhost.localdomain is the name used for private communications between two TCP/IP". My experience is that internal processes use localhost, not localhost.localdomain. In fact, I cannot think of a case where I have seen it being used. Do you have a cite? 2. You wrote "If your system had a dynamic IP address, various scripts were used to edit /etc/hosts to include an entry based on what the DHCP server returned." I've never seen that happen; I always thought /etc/hosts was immutable. Do you have a cite? May 14, 2011 at 18:27
  • 1
    Regarding, Debian Reference says: "The IP address in the second line of this example may not be found on some other Unix-like systems. The Debian Installer creates this entry for a system without a permanent IP address as a workaround for some software (e.g., GNOME) as documented in the bug #719621." And here's how /etc/hosts is generated.
    – x-yuri
    Feb 12, 2019 at 16:54

On my system, I have the following in /var/lib/dpkg/info/netbase.postinst:

create_hosts_file() {
  if [ -e /etc/hosts ]; then return 0; fi

  cat > /etc/hosts <<-EOF       localhost
        ::1             localhost ip6-localhost ip6-loopback
        fe00::0         ip6-localnet
        ff00::0         ip6-mcastprefix
        ff02::1         ip6-allnodes
        ff02::2         ip6-allrouters


My netbase version is 4.45.

I would expect that the first name on the line will be returned for a reverse lookup of the IP address, otherwise I doubt the order matters.

  • Yes, I have it in my netbase postinst too. Good catch! +1. Apr 22, 2011 at 21:26
  • Well, this isn't a complete answer, but nobody else responded. So I guess I accept this. :-) Apr 29, 2011 at 7:58
  • Judging from this answer /etc/hosts is created by debian-installer using netcfg package.
    – x-yuri
    Feb 12, 2019 at 15:15

I've wondered before why this file is set up the way this is, but the answer is not obvious.

Adding or removing a line from a text file is pretty easy to script.

Editing a line in a text file to add or remove components is much harder.

So it's really easy to write a script that runs "hostname -s" and "hostname -f", deletes from /etc/hosts and adds a new one with the results of hostname.

But it's a lot harder to write a script that removes whatever the hostname used to be from the line containing (without disturbing entries added manually by the operator) and then add the current hostname to the localhost entry.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .