266

This may be a bit of a noobish question, but I was taking a look at /etc/hosts on my new Xubuntu install and saw this:

127.0.0.1 localhost
127.0.1.1 myhostname

On most 'nixes I've used, the second line is omitted, and if I want to add my hostname to the hosts file, I'd just do this:

127.0.0.1 localhost myhostname

Is there a difference between these two files in any practical sense?

einpoklum
  • 1,652
  • 3
  • 21
  • 31
Tom
  • 3,213
  • 2
  • 20
  • 19
  • I wonder can i just delete the second line or will some process in debian/ubuntu regenerate the line and add it back? – simgineer Apr 04 '17 at 20:45
  • I still don't understand do we put the same hostname to the right of ```127.0.0.1``` and ```127.0.1.1``` or should the hostnames be different?? Or maybe ```127.0.0.1 localhost``` and ```127.0.1.1 actual_hostname```. – michal roesler Apr 27 '23 at 12:05

5 Answers5

200

There isn't a great deal of difference between the two; 127/8 (eg: 127.0.0.0 => 127.255.255.255) are all bound to the loopback interface.

The reason why is documented in the Debian manual in Ch. 5 Network Setup - 5.1.1. The hostname resolution.

Ultimately, it is a bug workaround; the original report is 316099.

U880D
  • 1,017
  • 2
  • 12
  • 18
Daniel Pittman
  • 5,842
  • 1
  • 23
  • 20
  • 9
    The actual reason: "Associating the system hostname with the latter had the unwanted effect of making 'localhost.localdomain' the canonical hostname associated with the system hostname. That is, 'hostname --fqdn' returned 'localhost.localdomain'." – cmroanirgo May 29 '15 at 20:58
  • I actually traced it back to this doc lists.debian.org/debian-boot/2005/06/msg00938.html and it appears that its because Thomas was feeling the need to use 1.1 instead of 0.1, which they are equivalent, correct me if im wrong, but that means this answer is really only a breadcrumb? – Brian Thomas Aug 02 '16 at 04:56
  • 1
    @BrianThomas that message suggests why they're not equivalent. They wanted `localhost` and `myhostname` to be distinct - otherwise, one would be an alias of the other. Note this doesn't work in IPv6 where there is only one loopback address. It can be avoided by using an NSS module as mentioned in the thread, because it can be more flexible than /etc/hosts and return different canonical names despite them having the same IP address. I know this because [my system is configured using such an NSS module](https://www.freedesktop.org/software/systemd/man/nss-myhostname.html). – sourcejedi Jul 21 '17 at 17:09
  • what happen if I put `127.0.0.1 my_host_name`? – Davide Oct 30 '19 at 11:49
  • 1
    It caused dnsmasq to return 127.0.1.1 clients so I had to remove it. – Deepstop Jul 02 '20 at 14:55
  • It's causing linux xterminals to redraw 100x slower than they should, it takes 2-3 seconds to redraw a xterm window. – Owl Oct 05 '22 at 15:15
58

To sum up the linked-to information:

  • It is (debatably) useful to have an entry in your /etc/hosts translating the machine's fully-qualified domain name into its permanent IP address.
  • debian-installer, and more specifically, its netcfg component, currently (up to March 2013 at least) creates this entry.
  • If the machine is not known to have a permanent IP address, the debian-installer still wants it to have that kind of entry.
  • The address 127.0.1.1 uses the loopback interface, answered by your own machine, just like 127.0.0.1 but is a distinct entry in /etc/hosts which can be considered separately from 127.0.0.1 if/when necessary.

Thomas Hood explains adding this entry as follows:

[This] will ensure that if the UNIX hostname is resolved then it will always be its own canonical hostname

but:

In the long run the UNIX hostname should not be put in /etc/hosts at all.

einpoklum
  • 1,652
  • 3
  • 21
  • 31
  • 3
    .. and so... ? must I user 127.0.0.1 for my fdqn? or 127.0.1.1? or the static lan ip? – realtebo Aug 27 '18 at 21:46
  • 1
    @realtebo: 1. It's useful, and thus it's added by the installer. 2. There is no "must" here; and it's only relevant when your FQDN doesn't have a permanent address. – einpoklum Aug 27 '18 at 22:29
  • @einpoklum On ubuntu 20 it seems to automatically add this entry to /etc/hosts at reboot even if I already have my hostname there with it's actual ip, and this screws up our services (as they listen on the wrong interface). Is there any way of preventing ubuntu from messing about with /etc/hosts on reboot? – CpnCrunch Jun 18 '21 at 16:34
  • 1
    @CpnCrunch: I'm 90% certain there's some configuration setting (in `/etc/default` maybe?) for disabling this behavior. That's what I'd try and do. – einpoklum Jun 18 '21 at 16:37
  • @einpoklum possibly, but I don't see any mention of it anywhere there, or in the man page for networkd-dispatcher or its scripts in /usr/lib/networkd-dispatcher (which would seem to be the obvious culprit). – CpnCrunch Jun 18 '21 at 16:51
  • @CpnCrunch: Then please ask about this at askubuntu.com and paste a link here. – einpoklum Jun 18 '21 at 17:09
  • I figured it out. I just need to comment out the update_etc_hosts line in /etc/cloud/cloud.cfg. It appears my (OVH) server was using DHCP to get its static ip from somewhere in OVH. I thought it best not to mess about with that, and removing update_etc_hosts works fine (it doesn't touch /etc/hosts any more). I made sure to put my host's static ip in /etc/hosts with the hostname and fqdn. – CpnCrunch Jun 19 '21 at 00:43
  • @CpnCrunch: So now, definitely post this as a question and answer, either here or on askubuntu. – einpoklum Jun 19 '21 at 07:55
18

I was curious myself, and i didnt like any of the other answer because they didnt seem to answer what i was looking for atleast.

The Answer: Looking back at this doc it almost appears as if Thomas was stating is "giving it another dedicated ip on the loopback allows it to be canonical".

Both point to your loopback. Using the following 127.0.1.1 is an actual IP, on the loopback, whereas 127.0.0.1 is either the device itself, or another ip on the loopback. Both end up on the same subnet, representing the loopback, but are separated by ip. They are equivalent dns wise, but separated because of having dedicated ip.

The point being, you can have all your entries on one line like this

127.0.0.1 localhost localhost.domain www.myfakednsname.com myakednsname.com

If your hostname is local, meaning doesn't have a global internet DNS entry mapped to an actual internet ip, then in this case Thomas was saying you NEED TO have the 2nd entry line, like this to dedicate it there (to canonical).

127.0.0.1 localhost localhost.localdomain
127.0.1.1 myfakednsname
Brian Thomas
  • 398
  • 3
  • 15
  • in all fairness, after i finally composed this to a way that made sense to me, i see thats pretty much what einpoklum was trying to explain it looks like in hindsight. – Brian Thomas Aug 02 '16 at 05:15
  • 2
    OK negative vote, not sure why. I still believe THIS is the BEST answer, or i wouldnt have put it, after landing here. the original answer helped, but didnt capture all the details. I would go with This one. – Brian Thomas Aug 10 '16 at 20:05
6

I read several answers around, and I'm frankly a bit confused.

I first tried to understand what is canonical hostname here.

What I can say is that @cmroanirgo is right in saying that on my Ubuntu laptop, invoking

hostname --fqdn

with /etc/hosts configured like this

127.0.0.1   localhost 
127.0.1.1   laptop

returns laptop, whereas changing the file like follows

127.0.0.1   localhost laptop

returns localhost.

What impacts this can have, I have no idea, except the fact that if you have software that binds to hostname, and you need to talk to it internally to your machine, don't expect to be able to use the "localhost" hostname to do the job, in this setup, since they end up resolving two distinct separate addresses.

kenlukas
  • 3,101
  • 2
  • 16
  • 26
Riccardo Manfrin
  • 161
  • 1
  • 1
  • 2
    One example implication: unattended-upgrades uses `socket.getfqdn()` (in python) for the mail subject. I want the UNIX hostname there to distinguish different machines (not localhost), so the variant with 127.0.1.1 seems correct or at least better to me. – Dario Seidl Mar 26 '20 at 11:49
  • Using `127.0.1.1` has downsides too! You cannot `telnet laptop 25` when the`smtp` service is configured to `listen on localhost` or even `listen on lo` (the interface). With `/etc/hosts` having two separate lines for `localhost` and `laptop` that **both** map to `127.0.0.1`, this _will_ work _and_ `hostname --fqdn` will still return `laptop` just fine. So In that regard, there's no need to fiddle with `127.0.1.1` at all! Indeed, the outlier is python's `socket.getfqdn()` (as used by `unattended-upgrades` ) that will insist on reporting `localhost` for such a setup. – cueedee Jun 09 '23 at 12:50
0

Antique question, but adding a different answer. If you use a line:

127.0.1.1 my_fqdn my_short_name

eg

127.0.1.1 server.domain.com server

The (on Ubuntu at least) Apache will pick up your correct hostname without having to enter it explicitly in the apache config. This is probably similar to comment in the answer above.

Nick Howitt
  • 1